Model-View-Control Architecture

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

Problem

The presentation logic 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

Application data-- implementations of the domain entities, events, descriptions, and roles described in the domain model-- are encapsulated in the Model subsystem.

Application logic-- implementations of the activity sequences represented in the business process model-- is encapsulated in the Model subsystem.

Presentation logic-- the user interface (control panels, windows, menus, etc.)-- is encapsulated in the View (output) and Control (input) subsystems.

The View subsystem depends on the Model and Control subsystems. The Control subsystem depends on the Model subsystem. None of these dependencies go the other way.

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.