Model-View-Control Architecture

Also called the Document-View or Model-View Architecture.

Problem

Presentation logic (user interface) is volatile, while application data and logic is stable. If application data and logic depends on the user interface, then changes to the user interface will propagate necessitate changes to the application data and logic as well.

Solution

Encapsulate application data and logic in a model component (class, package, or component).

A view provides some graphical or textual description of all or part of the model. Views might include bar graphs, pie charts, or text.

Views may also include controls or control panels that allow the user to input commands. Alternatively, these control panels could be separate from the views.

A controller receives commands from the controls and processes them. There might be one controller per view or control panel or one controller for all views.

Clearly views and controllers need access to the model. However, the model contains no dependencies on the views or controllers.

Structure

The Model subsystem usually interfaces with the Persistence subsystem so that application data can be saved to a database or file.

Behavior

Of course the View package may contain multiple windows and control panels that all need to be updated when the model is updated. We can solve this problem by introducing some sort of event notification mechanism.

Discussion

The Model-View-Control Architecture was popularized by the Smalltalk language. It is used extensively.