The Model-View-Controller architecture is an object-oriented framework and well-known design pattern for building applications and reusable GUI components. MVC prescribes a way of breaking an application or component into three parts: the model, view, and controller. The original motivation for this separation was to map the traditional input, processing, output roles into the GUI realm:
Input --> Processing --> Output
Controller --> Model --> View
The user input, system function and state, and visual feedback to the user are separated and handled by controller, model, and view respectively. Figure 10 represents the basic MVC triad and lines of communication.
The model is really the cornerstone of the triad. As its name implies, its job is to model some real-world system by emulating its state and functionality. Models define queries for reporting state, commands for altering state, and notifications to inform observers (views, for example) that a change in state has occurred. The controller is responsible for defining the behavior of the triad. Its job is to receive mouse and keyboard input and map this user stimulus into application response – for example, by executing the model's commands. The view manages a rectangular area of the display and is responsible for data presentation and hit testing. (Hit testing calculates the object at a given position on screen.) And due to its observer relationship with the model, new views can be defined and attached to a model while holding the model's interface constant.
Figure 10 shows the relationships between model, view and controller in a triad. The dashed lines represent weakly typed aggregation and the solid lines represent strongly typed aggregation. The model maintains a pointer to the viewport, which allows it to send the viewport weakly typed change notifications. Since it is a weakly typed relationship, the model references the viewport only through a base class that allows it to send notifications to the viewport.
In contrast, the viewport knows exactly what kind of model it observes. It has a strongly typed pointer to the model that allows it to call any of the model's functions. The viewport also has a weakly typed relationship with the controller. The viewport is not tied to a specific type of controller, which means that different types of controllers can be used with the same viewport.
The controller has pointers to both the model and the viewport and knows the type of both. Because the controller defines the behavior of the triad, it needs to know the type of both the model and the viewport to translate user input into application response.
The relationship between the model and viewport is actually defined by another design pattern. The subject-observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. In the case of MVC, the model is a subject and viewports are observers. See Section 4.2, "The Subject-Observer Pattern," for an overview and examples of this design pattern.
MVC is regarded as a classic example of a design pattern and has experienced resurgence in popularity as a result of recent publications on the subject.
The classic text Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma et al. ISBN 0-201-63361-2 discusses MVC and the Command design pattern. However, its coverage of MVC is minimal.
A more recent text, A System of Patterns: Pattern-Oriented Software Architecture by Frank Buschmann et al. ISBN 0 471 95869 7 offers more coverage of MVC and the Command Processor design pattern within the context of C++.
Copyright © Rogue Wave Software, Inc. All Rights Reserved.
The Rogue Wave name and logo, and Stingray, are registered trademarks of Rogue Wave Software. All other trademarks are the property of their respective owners.
Provide feedback to Rogue Wave about its documentation.