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 [http://c2.com/cgi/wikiModelViewControllerAsAnAggregateDesignPattern aggregate design pattern].
=Operation=
In broad terms, constructing an application using an MVC architecture involves defining three classes of modules.
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: # The user interacts with the user interface in some way (e.g., user presses a button) # A controller contains the input part of the user interface. # 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. # 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 (or direct from the data access layer - sometimes there is no domain logic to do). 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 view-agnostic. The controller does not pass domain objects (the model) to the view although it might issue a command telling the view to update itself. # The user interface waits for further user interactions, which begins the cycle anew.
=Benefits and liabilities=
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. We discuss some of those here.
==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 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==
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.
What does event driven mean Was there ever an application which did not respond to user events..
Just because an application responds to events does not mean it is event driven . Event driven means it spends much of its time waiting for an event and then takes action if and when an event occurs. Contrast this with some programs that do not respond to events at all, but simply do their job and terminate. For example, an operating system command to display the current time. It displays the time and is done; it does not wait for events. For more information, see: Event-driven programming
=Implementations=
The pattern was [http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html first described in 1979] by Trygve Reenskaug, then working on Smalltalk at Xerox research labs. The orginal implementation is described in depth in the influential paper [http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller]. ssssssssssss Smalltalk s MVC implementation inspired many other GUI frameworks such as:
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.
=See also=
=External links=
General information regarding MVC
Specific aspects of MVC or alternatives to MVC
=References=
|
|