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 .
© 2022 - 2024 — McMap. All rights reserved.