Model–view–controller

Model-view-controller (MVC) is a software architecture that separates an application's data model, user interface, and control logic into three distinct components so that modifications to one component can be made with minimal impact to the others.

MVC is often thought of as a software design pattern. However, MVC encompasses more of the architecture of an application than is typical for a design pattern. Hence the term architectural pattern may be useful (Buschmann, et al 1996), or perhaps an aggregate design pattern.

Operation

In broad terms, constructing an application using an MVC architecture involves defining three classes of modules.

• Model: The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g. calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).
• View: Renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the code which gathers dynamic data for the page.
• Controller: Responds to events, typically user actions, and invokes changes on the model and perhaps the view.
• Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention this data access layer, because it is understood to be underneath or encapsulated by the Model.

It's common to think of an application as having three main layers: presentation (UI), domain, and data access. In MVC, the presentation layer is split into controller and view. The most important separation is between presentation and domain; the V/C split is less so.

Though MVC comes in different flavors, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g., user presses a button)
2. A controller handles the input event from the user interface, often via a registered handler or callback.
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g., controller updates user's shopping cart). Complex controllers are often structured using the command pattern to encapsulate actions and simplify extension.
4. A view uses the model to generate an appropriate user interface (e.g., view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model should have no direct knowledge of the view. However, the observer pattern can be used to provide some indirection between model and view, allowing the model to notify interested parties of a change. A view object can register itself with the model and listen for changes but the model itself remains unaware of the view. The controller does not pass domain objects (the model) to the view although it might issue a command telling the view to update itself.
5. The user interface waits for further user interactions, which begins the cycle anew.

The 'model-view-controller' paradigm introduces the controller object in between the view (the GUI class) and the model (the object) to communicate between the other two objects. The actual implementation of the controller object can vary quite a bit, but the idea of an object to 'transform' events to changes in data and execution of methods is the essence of this pattern.

Advantages and disadvantages

Although widely used, MVC has both advantages and disadvantages compared to other design options, and individual circumstances should be used to choose the most appropriate design.

View instability vs. model stability

If constructed correctly, models can enjoy a fair degree of stability (owing to the stability of the domain model), whereas user interface code usually undergoes frequent and sometimes dramatic change (typically because of usability problems, the need to support growing classes of users, or simply the need to keep the application looking "fresh"). Separating the view from the model makes the model more robust, because the developer is less likely to "break" the model while reworking the view.

Attempting to join these two worlds in a hand coded method without architecture is very common, and results in the model object being polluted with knowledge of the interface, and vice-versa. This makes the code very inflexible and difficult to maintain. For this reason (among others), many programming shops develop the user interface design early in the process of design, and freeze the interface early. The unfortunate side effect of this is that the domain of the problem often isn't clearly understood by the programmers until late in the implementation process. Thus, just at the time that the developers are finally competent to create a good interface, they are kept from changing it. MVC models allow the code to be more flexible later in the development process, allowing for changes to be made at the time it makes sense to make them.

Implementations

The pattern was first described in 1979 by Trygve Reenskaug, then working on Smalltalk at Xerox research labs. The original implementation is described in depth in the influential paper Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller.

Smalltalk's MVC implementation inspired many other GUI frameworks such as:

• The NeXTSTEP and OPENSTEP development environments encourage the use of MVC. Cocoa and GNUstep, based on these technologies, also use MVC.
• Microsoft Foundation Classes (MFC).
• The Java Swing GUI library.
• The Qt Toolkit since Qt4 Release.

More recently there have been attempts to apply MVC architectures for web-based interfaces. In the design of web applications, MVC is also known as a "Model 2" architecture in Sun parlance. Complex web applications continue to be more difficult to design than traditional applications, and MVC is being pushed as a potential solution to these difficulties.

Beware: many applications which claim to comply with this much misunderstood pattern in fact do not achieve the required separation of model and view.

• JavaServer Faces, Apache Struts and Webwork2 are currently the most popular web oriented MVC implementations. Struts works at a page level; JSF works at a component level .
• XForms is an approach on building web based applications based on MVC, under development by W3C
• The WebObjects development/deployment environment is strongly based on MVC.
• MVC frameworks written in PHP (Wiki)
• Fusebox
• Mach-II
• Maypole
• Catalyst
• Wicket
• Tapestry
• ZNF
• Phrame
• Symfony
• Apache Cocoon
• Orbeon
• Ruby on Rails
• TurboGears
• Model Glue For ColdFusion
• Django
• Smart3

See also

• Design patterns
• Three-tier (computing)
• The Observer design pattern
• The Template design pattern
• The Bong Balais design pattern

External links

General information regarding MVC

• MVC Description in the Portland Pattern Repository
• Discussion of JavaServer Pages Model 2 architecture
• Model View Controller Overview
• Presentation

Specific aspects of MVC or alternatives to MVC

• Core J2EE Patterns - Front Controller
• Holub, Allen (1999). "Building user interfaces for object-oriented systems". {{cite news}}: Unknown parameter |org= ignored (help)
• Gresh, John E. (2004). "The Collection Switch Design Pattern" (PDF). {{cite news}}: Unknown parameter |org= ignored (help)
• MVC versus "Event Driven" Discussion
• What's a Controller Anyway

References

• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Machael Stal (1996). Pattern-Oriented Software Architecture. John Wiley and Sons. ISBN 0-471-95869-7.{{cite book}}: CS1 maint: multiple names: authors list (link)