Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
While going through university and from following the development of SO, I've heard a lot about the Model-View-Controller architectural design pattern. I inadvertently used the MVC pattern even before I knew what it was, and still use it in my everyday job. From what I've seen, it's probably the most popular pattern used today. What I haven't heard much about though, are the alternative patterns you can use instead of MVC. What options are there, and for what reasons would you decide to use them over MVC? I'm also interested in knowing the types of systems they are typical of being used for. Finally, what are the pros and cons that come along with using them?
Passive View - http://martinfowler.com/eaaDev/PassiveScreen.html
Supervising Controller - http://martinfowler.com/eaaDev/SupervisingPresenter.html
Model-View-Presenter - http://martinfowler.com/eaaDev/ModelViewPresenter.html
My personal favorite is the Passive View. More testable than others I've seen including MVC.
Some other architectural patterns including MVC.
Layered Systems
TCP/IP
Object-Oriented Organization
Model-View-Controller, Presentation-abstraction-control, Model View Presenter and Model View ViewModel.
Examples would be ASP.NET's MVC, Ruby on Rails, and bunch of others.
Event Based, Implicit invocation
Browser environment (DOM)
Pipe and filter architecture
Unix pipes
Repositories
Table Driven Interpreters
You may also find this paper by Garlan & Shaw on Software Architecture a nice read.
Another noteworthy link would be the article on architectural patterns at Wikipedia.
I've occasionally seen MVC without the C, where the view listens for changes in the model's data and alters rendering accordingly, and where the methods in the model are bound to event handlers for the view.
For projects where the view is by necessity tightly couple with the data (such as when there are visual components that directly relate to the model or attributes of the model), this can be rather useful, as it cuts out the "middle man."
I think many would argue, though, that this is still MVC, just a hybridized version, and that the bindings established between the view and model are controller logic.
Well, there's Model-View-Presenter, but I think you'll find that the most common "alternative" to MVC is really a lack of proper separation. As an extreme example, consider classic ASP pages where HTML, VBScript and SQL are found side-by-side in the same file. (That's not a bash of ASP — you'll find plenty of such examples in other languages.)
Although the above answers are quite correct, I think it's much more important to note that the words "design pattern" are completely unknown to 90% of all people who create software. They just start writing code.
The challenge is not selecting the best design approach, it's convincing others that design has value.
Well it is quite old now. I would like to mention one more (in the interest of info for additional knowledge) is PresenterFirst patrern
Here is more information on the same:
http://en.wikipedia.org/wiki/Presenter_First
http://www.atomicobject.com/pages/Presenter+First
HTH
The Presentation-Abstraction-Control (PAC) family of patterns, where interface/interaction is handled by a hierarchy of agents.
The wikipedia article is not great
http://en.m.wikipedia.org/wiki/Presentation-abstraction-control
In the Lift web framework we use a View First approach. Basically a view is composed of one or more snippets (somewhat similar to controllers) and snippets can be nested. This works very well with HTML and Scala's built-in XML processing capabilities.
You can roll your own MVC with the current ASP.NET framework and still keep the postback model.
http://www.codeproject.com/KB/aspnet/RollingYourOwnMVCwithASP.aspx
What about the Observer pattern. If I am not mistaken , MVC was introduced in Smalltalk and thereafter several publish/ subscribe patterns have come into picture.
The observer pattern (a subset of the publish/subscribe pattern) is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. It is mainly used to implement distributed event handling systems.
Ex : The Save button gets enabled in an editior, only when there is data to be saved. Another example of the observer pattern is Document View architecture in MFC, where in the view gets updated when the document changes .
Related
I have two models, lists and lists_items
I have a basic crud structure for them.
I've also set the hasMany(in lists) and belongsTo(in lists_items).
What I want now is to add an option to edit the list_items themselves in the edit view of the parent list.
Please advice me how to create the proper MVC for that.
(I just can't find out what are the correct element/components/etc that I should use 'to do it right', I can simply glue together some MVC pieces and it will work, but I had enough of classic asp)
;-)
I don't think I am answering your questions because there are other problems I see in your setup (at least I assume there is).
Your naming convention: "lists_items" is usually used for a HABTM relationship, and if it's a HABTM you need to put the words in alphabetical order like: "items_lists". If this is a standard belongsTo, you should name the table: "list_items". This is just per convention.
And you should probably use bake to get familiar with the CakePHP file structure and you can study the relationship code in the models.
Being able to edit related "parent" model data is usually not difficult if you are following convention and reading the manual about relationships.
Keep in mind "doing it right" in CakePHP is following the convention that was laid out in the manual. I know NOT every single thing and detail is covered in the manual as a lot of it has to do with general Object Oriented concepts and general programming concepts (understanding arrays etc).. Learning CakePHP effectively is not an overnight process and the only suggestion I can make is practice, practice, practice and read, read, read the manual over and over again :) Best luck.
In my experience code behind UI can easily get ugly, and inorganized, e.g. long functions, lots of variables etc.
How do you manage the code behind UI?
The MVC pattern is often used to impose some structure and organisation.
Following the principles of SOLID OO design and similar ideas helps.
It depends on your programming-language.
Threre are a lot of QA-Tools for different languages. Have a look at wikipedia
Which languages and techniques do you use?
One solution is to use 'immediate mode' UIs. It basically boils down to only caring about the UI element you're currently focussed on and binding the variables with data-side app variables. This is the opposite of retention mode UIs
Great video here.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What are MVP and MVC and what is the difference?
I don't see any difference between MVP and MVC software architectures (MVC where controller implements mediator pattern), other than the name by which you call the mediator (presenter vs controller)
Can someone provide a clear explanation?
I care because I have a reasonable understanding of MVC via cocoa and I'm wondering how that knowledge will have to grow to understand MPF/C#/.NET
Darin's provided a good link. I'd say there are a couple key differences, but a lot of similarity. MVP's view is even simpler than MVVC's - it doesn't know about the model. That makes it easier to get everything covered by tests, IMHO. Also, it makes it easier to provide alternate views, for example, if you want both a GUI and a CLI. But, read the article, it covers the topic well.
According to Sun and Msdn it is a design pattern.
According to Wikipedia it is an architectural pattern
In comparison to design patterns, architectural patterns are larger in scale.
(Wikipedia - Architectural pattern)
Or it is an architectural pattern that also has a design pattern ?
Which one is true ?
MVC is more of an architectural pattern, but not for complete application. MVC mostly relates to the UI / interaction layer of an application. You're still going to need business logic layer, maybe some service layer and data access layer. That is, if you're into n-tier approach.
Why does one of them have to be true?
Both can be true, depending on point of view.
MVC can be an architectual pattern, if it forms the basis of the application architecture.
It can also be seen as simply a design pattern, an abstract notion that is applicable to any application.
Design patterns say how to write code effectively (considering Code Metrics).
A few benefits:
Easily Maintainable
High Re-usability
Readable because of abstractions
Architectural patterns say how to utilize resources effectively.
Parallel tasks execution like programmers and graphic designers can work parallel.
Multiple technologies can be utilized to build a software.
In MVC,
a). Views can be created using javascript templates and also html can be used
b). Controllers can be written .NET framework and
c). Models can be written in Java - a java service may be used that returns only json data.
While in design pattern, a pattern can't be implemented in which
code can be written in multiple technologies like AdminUser class in Java,
Customer class in C#, Partners class in Php and a factory pattern in Ruby
:); hmmm..so easy?:)
I know that it's been answered awhile ago, but no one has yet mentioned the book that made MVC famous: Pattern-Oriented Software Architecture (POSA), by Buschmann, et al published in 1996. Though not as widely read as the Design Patterns book, by Gamma, et al, POSA is one of the foundational books used by the patterns community.
Oh, and POSA very clearly identifies MVC as an architectural pattern. My hunch is that MS and Sun are just being sloppy and calling every pattern a "design pattern".
The design patterns inside the Model/View/Controller (MVC) triad of classes include and may not be limited to:
Observer, decoupling objects so that changes to one (the model) can affect any number of others (the views) without requiring the changed object (the model) to know details of the others (the views).
Composite, which lets us treat a group object (a composite view) just like we treat one of its individual objects (view components).
Strategy, where a view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller.
Factory Method, specifying the default controller class for a view.
Decorator, adding scrolling to a view.
Reference
Pages 4 to 6 (Section 1.2 Design Patterns in Smalltalk MVC)
Pages 293 to 304 (Observer design pattern)
Pages 163 to 174 (Composite design pattern)
Pages 315 to 324 (Strategy design pattern)
Pages 107 to 116 (Factory Method design pattern)
Pages 175 to 185 (Decorator design pattern)
Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994.
I think both are true. If you're looking at a particular instantiation of MVC in a framework like Ruby on Rails, that instantiation is more of a design pattern. If you look at MVC as a general concept, it's more of an architectural pattern.
If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions. … Some of the purists out there will inevitably have qualms with what I refer to as “MVC”. Feel free to leave a flaming comment on the message board at the bottom of this Web page. I will gladly entertain different perspectives on what MVC means, but keep in mind that I do not care.
Josh Smith
MVC always mentioned and introduced as/in presentation layer in software architecture books.
Read these books:
Architecting Microsoft.NET Solutions for the Enterprise (Microsoft press)
Professional ASP.NET design patterns (Wrox)
Enterpise Solutions Patterns Using Microsoft.NET (Microsoft press)
Patterns of Enterprise Application Architecture (Addison Wesley)
A Practical Guide to Enterprise Architecture (Prentice Hall)
And according to Martin Fowler they are GUI architectures: Martin Fowler-GUI architectures
It depends on the size of the application, as it only affects GUI related classes, in a small one (mostly GUI) it could be considered an architectural pattern whereas in a huge one it would just be a design pattern that you apply to the GUI code (could be 10% of the apps code).
MVC is architecture pattern. Very clearly stated and shown at http://molecularsciences.org/zend/mvc_model_view_controller
How do YOU factor your Domain (namespaces), in Domain Driven Design?
I have been moving to the following concept:
Project.Entity
Project.Entity.Abstracts
Project.Entity.Entities
Project.Entity.Extensions
Project.Entity.Immutables
Project.Entity.Interfaces
Project.Entity.Repositories
For example, I have an entity in a CMS called "Content". So, I would create a project called Project.Content, and factor the classes to look like:
interface IContent
class Content : IContent
interface IContentRepository
class ContentRepository : IContentRepository
This "Content" Entity model would have its own namespace.
But, I am finding it does not scale well in a large Enterprise environment with well over a dozen projects (try 18) of "Entity" models. I end up with a solution with over a dozen projects, some of which only have 2 or 3 classes (i.e. UrlRewriter). Also, I find myself referencing other projects just for their Interfaces. I feel like this is poluting my domain; while not concret references, it's sometimes difficult to keep from circular references.
So, I fall back to the "Layer" concept at times...
I am wanting to know how other DDD experts are factoring Enterprise-size applications. Please feel free to recommend books and articles.
And thanks in advance!
One think that I do is to add something that identifies the bounded context to it.
Ps. to make sure it is clear why, check both links on bounded context:
http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html, http://devlicio.us/blogs/casey/archive/2009/02/11/ddd-bounded-contexts.aspx
I use follow the .NET guidelines. I find them very intuitive and they allow you to setup namespaces such that you don't need to import anything you don't need.
I would never impose a strict naming convention for the feature level. The design of each different project should guide that.
I similarily to you have found out that having load of projects becomes a pain to manage.
I prefer the
Project.Domain
Project.DataAccess
Project.Presentation (presenters and such)
Project.Gui (in case of a winforms app)
setup.
In a way making things simple helps a lot when things go bad.
The question is what do you gain when you create another project ? (it is very easy to do so, almost to easy)
Will you ever want to use that project independently or not ? You might end up with the resulting .dlls so coupled you can't even deploy them without being exactly the same versions etc. in that case there is little reason for splitting it up and cluttering your IDE)
You can always move things to a new project later if the need arises, it is somewhat painfull, but by that time you would have a good reason to do it apart from just the feeling that is the way it is done.