Design Patterns: Model-View-Controller
A Compound Design Pattern

What is the Model-View-Controller (MVC) Compound Design Pattern?

The MVC "compound" design pattern, or "framework", or "architecture", was originally developed by Professor Trygve Reenskaug at Xerox PARC in 1978. Its purpose at that time was to provide convenient GUI support in the programming language Smalltalk. Nowadays the MVC is widely used in various GUI contexts, and in particular in the design of Swing components in Java. (See Peter van der Linden's Just Java, published by Prentice-Hall.)

Here is the basic formulation of the MVC design pattern:

• Name
  The name of the design pattern is Model-View-Controller.
• Intent
  The intent of this design pattern is to help keep the user interface separate from the rest of the program.
• Solution
  The MVC pattern solves this problem by dividing a program into three parts:
  • The Model, which contains the computational part of the program, i.e., which provides access to the system's core functionality, the system's state information, and a state change notification system.
  • The View, which presents the user's "view" of the system. That is, this is the part of the system that displays the Model to the user, registers with the Model for state change notification, and retrieves state information from the Model.
  • The Controller, which handles interaction between the user and the View, i.e., which intercepts user events from the View, interprets those events, and calls the proper methods on the Model or the View in response to those events, and registers with the Model for state change notification, if interested.
  In this scheme the Controller provides the communication between the Model and the View objects, and may be either a separate class or may be inherent in either the Model or the View.
• Consequences
  Although it has been very widely used for some time, the MVC does have some shortcomings:
  • Its emphasis is on data: Instead of asking an object to do something with its data, the View asks for the data and then displays it, which can also contribute to inefficiency.
  • Tight coupling: Both View and Controller are tightly coupled to the Model's public interface.
  • Depending on how state change notifications are handled, inefficiencies can creep in. Queuing them may help, as is done in the AWT event model when redrawing the screen—instead of redrawing after each event, several events are queued, and are then followed by a single redraw.

Another Discussion of the Model-View-Controller Design Pattern

The following excellent short discussion of the MVC design pattern is adapted from an Objective Toolkit Pro whitepaper by Dean Helman. See http://ootips.org/mvc-pattern.html.

The MVC paradigm is a way of breaking an application, or even just a piece of an application's interface, into three parts: the model, the view, and the controller. MVC was originally developed to map the traditional input, processing, output roles into the GUI realm:

Traditional: Input      --> Processing --> Output
Modern GUI:  Controller --> Model      --> View

The user input, the modeling of the external world, and the visual feedback to the user are separated and handled by model, viewport and controller objects. The controller interprets mouse and keyboard inputs from the user and maps these user actions into commands that are sent to the model and/or viewport to effect the appropriate change. The model manages one or more data elements, responds to queries about its state, and responds to instructions to change state. The viewport manages a rectangular area of the display and is responsible for presenting data to the user through a combination of graphics and text.

The model is used to manage information and notify observers when that information changes. It contains only data and functionality that are related by a common purpose. If you need to model two groups of unrelated data and functionality, you create two separate models.

A model encapsulates more than just data and functions that operate on it. A model is meant to serve as a computational approximation or abstraction of some real world process or system. It captures not only the state of a process or system, but how the system works. This makes it very easy to use real-world modeling techniques in defining your models. For example, you could define a model that bridges your computational back-end with your GUI front-end. In this scenario, the model wraps and abstracts the functionality of a computation engine or hardware system and acts as a liaison requesting the real services of the system it models.

The view or viewport is responsible for mapping graphics onto a device. A viewport typically has a one to one correspondence with a display surface and knows how to render to it. A viewport attaches to a model and renders its contents to the display surface. In addition, when the model changes, the viewport automatically redraws the affected part of the image to reflect those changes. There can be multiple viewports onto the same model and each of these viewports can render the contents of the model to a different display surface.

A viewport may be a composite viewport containing several sub-views, which may themselves contain several sub-views.

A controller is the means by which the user interacts with the application. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button or chooses a menu item, the controller is responsible for determining how the application should respond.

The model, viewport and controller are intimately related and in constant contact. Therefore, they must reference each other. The picture below illustrates the basic Model-View-Controller relationship:

                 +------------+
                 |   Model    |
                 +------------+
                /\ .          /\
                / .            \
               / .              \
              / .                \
             / \/                 \
      +------------+ <------ +------------+
      |    View    |         | Controller |
      +------------+ ......> +------------+

The figure above shows the basic lines of communication among the model, viewport and controller. In this figure, the model points to the viewport, which allows it to send the viewport weakly-typed notifications of change. Of course, the model's viewport pointer is only a base class pointer; the model should know nothing about the kind of viewports which observe it. By contrast, the viewport knows exactly what kind of model it observes. The viewport also has a strongly-typed pointer to the model, allowing it to call any of the model's functions. In addition, the viewport also has a pointer to the controller, but it should not call functions in the controller aside from those defined in the base class. The reason is you may want to swap out one controller for another, so you'll need to keep the dependencies minimal. The controller has pointers to both the model and the viewport and knows the type of both. Since the controller defines the behavior of the triad, it must know the type of both the model and the viewport in order to translate user input into application response.

List of All Topics