MVC Pattern - Model View Controller

Divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.

Example: Imaging a drawing application like Windows Paint. Events are scrolling the page, drawing a line. View is the line representation, etc.

The model component contains the functional core of the application. It encapsulates the data, and exports procedures that perform application-specific processing. Controllers call these procedures on behalf of the user. The model also provides functions to access its data that are used by view components to acquire the data to be displayed.

View components present information to the user. Different views present the information of the model in different ways. Each view defines an update procedure that is activated by the change-propagation mechanism. When the update procedure is called, a view retrieves the current data values to be displayed from the model, and puts them on the screen. During initialization all views are associated with the model, and register with the change-propagation mechanism. Each view creates/initializes a suitable controller. There is a one-to-one relationship between views and controllers. Views often offer functionality that allows controllers to manipulate the display. This is useful for user-triggered operations that do not affect the model, such as scrolling.

The controller components accept user input as events. How these events are delivered to a controller depends on the user interface platform. Events are translated into requests for the model or the associated view. Each view has an associated controller component. Controllers receive input, usually as events. Events are translated to service requests for the model or the view. The user interacts with the system solely through controllers.

The separation of the model from view and controller components allows multiple views of the same model. If the user changes the model via the controller of one view, all other views dependent on this data should reflect the changes. The model therefore notifies all views whenever its data changes. The views in turn retrieve new data from the model and update the displayed information. This change-propagation mechanism is described in the Publisher-Subscriber pattern.

The change-propagation mechanism maintains a registry of the dependent view components within the model. All views and also selected controllers register their need to be informed about changes. Changes to the state of the model trigger the change-propagation mechanism.

If the behavior of a controller depends on the state of the model, the controller registers itself with the change-propagation mechanism and implements an update procedure. For example, this is necessary when a change to the model enables or disables a menu entry.


  • Views do not create controllers
  • View/controllers do not register with model (like most Java frameworks; JSP and Servlets do not register with the model)
  • There might not be a change propagation mechanism and views are not notified of the model changes. Model is just pulled to view via controllers
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License