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 the view component can be made with minimal impact to the data model component.

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 (http://c2.com/cgi/wiki?ModelViewControllerAsAnAggregateDesignPattern).

Contents

1 Operation 2 Benefits and Liabilities 2.1 View Instability vs. Model Stability 2.2 Event Driven 2.3 Coupling of Model and Controller 2.4 Platform Independence 3 Implementations 4 See also 5 External links 6 References

Operation

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

• Model: This is the domain-specific representation of the information on which the application operates.
• View: This renders the model into a form suitable for interaction, typically a user interface element.
• Controller: This responds to events, typically user actions, and invokes changes on the model or view as appropriate.

There exist object-oriented frameworks which provide much of the functionality needed in each case.

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

1. user interacts with the user interface in some way (e.g., user presses a button)
2. controller receives notification of the user action from the user interface objects
3. controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g., controller updates user's shopping cart)
4. model notifies the view of changes, sometimes via the controller, or perhaps using the Publish-Subscribe pattern.
5. view uses the model to generate an appropriate user interface (e.g., view produces a screen listing the shopping cart contents). Note: In some implementations, the view does not have direct access to an external model -- instead, the controller pushes the data from the external model into the view.
6. user interface waits for further user interactions, which begins the cycle anew.

Benefits and Liabilities

View Instability vs. Model Stability

If constructed correctly models can enjoy a fair degree of stability (owing to the stability of the domain being modeled), whereas user interface code usually undergoes frequent and sometimes dramatic change (owing to 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 stitch these two worlds together 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 that make sense at the time it makes sense to make them.

Event Driven

The event-oriented nature of most modern GUIs is characterised by complex event handling. Each time the mouse moves, a button is clicked, or a key stroke is input, one or more events are generated. The code to handle these events at the lowest level is complex and difficult to write.

In contrast, objects in object oriented programming are composed of methods and data members that attempt to model something from the domain of interest. The best models are fully encapsulated, meaning that they implement every aspect of that real world object of interest to the domain of interest, and that they don't have any extra code that doesn't model the real world. Encapsulation also means that the class is implemented in such a way that the internal representation of data is not exposed to the user of the object.

The impedance mismatch between these two worlds, that of events, and that of objects, is something that's been recognized for a long time. Getting these two worlds to cooperate requires a lot of 'glue code' to make them work together.

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.

Coupling of Model and Controller

Although the model and controller are separated according to the principles of MVC, in practice they are closely coupled. A change to the data model will often require a change to the controller. This is seen by some as contrary to the encapsulation principle of object-oriented programming.

Platform Independence

The MVC design also allows programs written in otherwise platform-specific languages to be almost completely platform-independent. Since the model and controller generally have no knowledge of the view, the programmer is free to implement both in a cross-platform language such as C or C++.

As a result, the hardest part of porting the application is redesigning the interface (view) for the new operating system. The platform-specific language (such as Objective-C/Cocoa) is only used to notify the controller of user events and to respond to changes in the model.

Theoretically, an application written entirely under the Cocoa framework for Macintosh could easily be ported to Windows under the .NET framework, as long as the model/controller is written only in C++. All that would have to be done is to redesign the view in Visual Studio, and plug it into the existing model/controller, which is quite easy compared to the daunting task of rewriting the entire core of the program.

Implementations

The pattern was first described in 1979 (http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html) by Trygve Reenskaug, then working on Smalltalk at Xerox research labs. This original implementation inspired many other GUI frameworks such as:

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

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.

• JavaServer Faces , Jakarta Struts and Webwork2 are currently the most popular web oriented MVC implementations. Struts works at a page level; JSF works at a component level.
• The WebObjects development/deployment environment is strongly based on MVC.
• Fusebox
• Maypole
• Ruby on Rails
• Mojavi
• Tapestry
• ZNF

See also

• Design patterns
• Three-tier (computing)

External links

General information

• Description in the Portland Pattern Repository (http://c2.com/cgi/wiki?ModelViewController)
• Core J2EE Patterns - Front Controller (http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html)
• Dicussion of JavaServer Pages Model 2 architecture (http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html)
• MVC-Frameworks written in PHP (Wiki) (http://wact.sourceforge.net/index.php/MvcFrameworksWrittenInPhp)
• Template:Citenewsauthor

Specific implementations

• Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html)
• Fusebox (http://www.fusebox.org/)
• Mach-II (http://www.mach-ii.com/)
• Maypole (http://maypole.perl.org/)
• Catalyst (http://catalyst.perl.org/)
• Ruby on Rails (http://www.rubyonrails.org/show/HomePage)
• Ruby on Rails (http://www.rubyonrails.org/show/HomePage)
• Model Glue For Coldfusion (http://www.model-glue.com/)

References

• Template:Book reference

---

• .mvc is also the file extension for MivaScript files.
• MVC is Move Character in the IBM System/360 instruction setde:Model View Controller

es:Modelo Vista Controlador eo:MVC fr:Modèle-Vue-Contrôleur