CS294 Pattern Project: Model-View-ControllerNameProblemContextForcesSolutionModelViewControllerInvariantExamplesKnown UsesRelated PatternsReferences AuthorsCS294 Pattern Project: Model-View-ControllerNameModel-View-ControllerProblemApplications often need to present data to an client--a human user or another program--sothat the client can inspect, manipulate, and comprehend it with ease. How do you designsuch a system, which fits a sensible mental model of the data, provides intuitive usabilityand responsiveness, and is modular in implementation?ContextIn applications which have a client, the architecture should allow the client to interact withthe data and change it, updating the client interface with the new data. For the sake ofmodularity, it is desirable to divide an application with this kind of interaction into anarchitecture that separates out the data, its manipulation, and its presentation to the client;this allows the application to be easily extended by modifying the correct subsystem.Ideally, the application is centered on the data itself and its manipulation. There may be anumber of simultaneous clients interacting with the same data, which brings the problemssimilar to those in repository-style architecture, such as those associated with mergingconflicting changes to the data. More interestingly, a single client may want to have multipleviews, with some coordination between them.ForcesThe following forces create tensions which determine the architecture:• Responsiveness and programmability/maintainability: When a client initiates anaction, the system should respond in a reasonable time, where the meaning of"reasonable" may be application-dependent. Meanwhile, the code behind the systemas a while must still be easily amenable to changes and fixes, and thus must avoidpremature optimization which may result in unnecessary obfuscation.• Fault tolerance/correctness and scalability: Data may be lost and communicationlinks can fail, especially in network and web-based applications, and further datastorage can fail. Multiple clients may attempt modifying the system simultaneouslyresulting in conflicts. But the system must also be easily scaled to potentiallyaccommodate very large datasets, high throughput, and a large number of clients.• Presentation and Portability: The data must be presented to the client in an easilycomprehended and visually appealing manner. There may need to be more than onedistinct way of displaying the data, and the client may wish to have some freedomin how to view it. However, the client may wish to interact with the data through avariety of devices, which may each require different interfaces.SolutionDivide the application into three interacting subsystems: the model, the view, and thecontroller.Image Source: Sun Microsystems (http://java.sun.com/blueprints/patterns/MVC-detailed.html)ModelThe model is the data store and its related components. Any logic relating pieces of rawdata, as well as the data store itself, are encapsulated in this module. Any relations betweendata items are specified in and maintained by the model. At minimum, the model exposesan interface to read, write, and modify the data. This alone suffices for constructing apassive-model MVC (Model-View-Controller) system, in which the model is unaware ofexistence of controllers and views. If the model changes because of sources outside theMVC triad, then there needs to be an update mechanism that notifies views/controllers ofthe change. Still, the model is typically only loosely aware of the views or controllers as thelisteners of the state-change event. In a parallel environment, the model enforces atomicity,ensuring any interaction, even in parallel, with the model is safe.ViewThe view, also referred to as a viewport, presents the model to the client. While both theview and the controller handle requests from the client, the view only handles requests fromthe client which change the way the model is displayed to it. The controller, discussedbelow, is reserved to handle client requests to alter the model. Both the view and controllermake use of the interface exposed by the model in order to accomplish these goals.Each view in the Model-View-Controller pattern has a distinct use; one can think ofproviding a different view for each class of client, with each view providing interactionstuned to the client's particular class. Alternatively, a single client may wish to view datacontained in the model according to a variety of available schemes. For instance, a humanclient may wish to view a document as HTML, as a PDF, or as XML. The view is responsiblefor providing this variety of renderings of the underlying model.ControllerThe controller interacts with both the view and the model, allowing the client to change themodel, if the client has permission via the model. It is not an omnipresent piece of thepattern; some interactions (such as changing the ordering of data presentation in a view)do not require consulting the controller. However, all write and modify operations shouldpass through the controller, which is responsible for properly updating the data andpresenting updated views to the client. The controller also passes along rule changes, suchas permissions modifications or the addition of novel datatypes, to the model.This separation of the three pieces improves maintainability and programmability byallowing each piece to be updated without changing all three--often referred to as"separation of concerns." For example, adding an "administrative" interface to anapplication does not need involve changing the model. In addition, it preserves faulttolerance and correctness by making the model, in its roll as a data controller, ensure thatall updates to the data are correct. This not only improves the maintainability and ease withwhich the code can be changed, but also enables more parallel code development and moredeveloper specialization.Lastly, scalability is improved because views, which do not need write access to the data,can be independently run; the controller and model are responsible for synchronization.Thus read-only access is much lighter weight than full write access, and full write access hasthe arbitration in the model.Invariant1. The controller is the only piece that writes directly to the model and preservescorrectness.2. The client only interacts with the view.3. The controller interacts with the view and indirectly with the client to update themodel.4. The
View Full Document
Unlocking...