Model-View-Controller (MVC)
Problem: The Model-View-Controller (MVC) is a commonly used and powerful architecture for GUIs. How does it work?
Dean Helman wrote (an extract from Objective Toolkit Pro whitepaper):
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:
Input –> Processing –> Output
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:
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.
More info:
Ralph Johnson, Model-View-Controller as an Aggregate Design Pattern
Steve Burbeck, How to use Model-View-Controller
Object Arts, Model View Controller
