About MVC

One of the central issues of programming is finding structures. To structure a program, one has to identify purposeful decompositions of the code into intelligible, maintainable and reuseable parts.

MVC gives you a framework to structure an user interface as needed and purposeful. Being a framework, MVC does not enforce one single approach; rather, it provides facilities that you can use to give your application as much structure as needed.

The acronym MVC stands for Model-View-Controller. MVC is a way to structure an application - in modern terminology, MVC is a design pattern.

One important experience with the MVC pattern is that it facilitates the implementation of reuseable controllers and reuseable views. Reuseability of views and controllers has an enormous benefit: It allows a developer to concentrate himself on the implementation of the application model.

The essential idea of the MVC pattern is to split an application into three functional elements with distinct responsibilities and well-defined inter-element communication.

These functional elements are

• the model, which has the responsibility to store and to keep up to date all application-relevant data
• the view, which has the reponsibility to draw and to keep up to date a visual presentation of the application
• the controller, which has the responsibility to process all input and to inform either the view or the model (or both) about received input that may require an activity from the side of the notification recipient.

The relationship between an model and its associated views is special: Views act as observers of their respective models. The Smalltalk dependency mechanism is used to implement this relationship. An observer registers itself as a dependent object of the instance that it observes.

This diagram shows the flow of messages in Squeak MVC. Other implementations of MVC may implement slightly different conventions.

The communication paths between these functional units are these:

• view messages
  A controller sends these messages to its view to inform the view about received input. The view may display some visual hint.
  Example:
  • A ScrollController informs the view that scrolling is required.
  • A MouseMenuMontroller informs the view that a menu is needed.
• controller messages
  A view sends these messages to its controller to request some support from the controller. Most views do not communicate with their controllers, but some do.
  Example:
  • A PluggableTextView requests display support from a ParagaphEditor.
• edit messages
  A controller sends these messages to its model to inform the model about a completed edit activity.
  Example:
  • A ListController informs its model that an item was selected.
• change messages
  A model does not directly communicate with its views, it does not even even store direct references to its views. The views are registered as dependents of the model. To inform its dependents about a change, the model sends a change message to itself.
  Example:
  • A model sends either the message changed or a message like changed: <argument> to itself. That message is translated into update messages that are sent to the dependents of the model. Every dependent view examines all received update messages and decides what to do.
• data requests
  A view sends these messages to its model to obain up-to-date data to display.
  Example:
  • A PluggableListView requests a collection of strings from its model. Typically this happens as a reaction to a received update message.
  • A view asks its model to provide a situation-conformant menu.

A controller cooperates with exactly one view and one model. It has permanent references to its view and to its model. Likewise, a view cooperates with exactly one controller and one model. (Views that observe several models are possible, but rare.) A view has permanent references to its controller and to its model(s). The position of the model in the MVC triad is different:

• A model should be implemented in a way that allows for its independent use, that is without a view.
• A model never references a controller nor a view.
• Most models are able to support more than one view.
• A model that has to cooperate with views, registers these views as its dependents.
• All communication of a model with its views is mediated by the dependency mechanism, which translates a change message sent to the model into update messages sent to the dependent objects - usually views. This is a very narrow protocol, but it is sufficient to inform views about changes that may require an action from the side of the views.

Controllers

The controller delegates all requested activities to either its view or its model.

• Requests for a change of a visual presentation are delegated to the view,
• requests that may change the internal state of the application are delegated to the model.

The controller interprets all user input. When you write different controllers for one view type, you can create views of that type that exhibit different behavior to user input. This possibility is not always exploited as it could be.

Example

Text editors are implemented as specialized controllers. The most frequently used text editor is the ParagraphEditor, its subclass StringHolderController is a dedicated controller for a StringHolderView.

ParagraphEditor is a very flexible general text editor and a very suitable superclass for specialized text editors. Such specialized editors may add features like code formatting or syntax coloring. Regrettably, all these special features were added to ParagraphEditor where they are quite annoying when you do not need them.

Views

We distinguish pluggable views that work fine with unstructured models, and dedicated views that work best with model components. This tutorial will give examples for both types of views.

The window of an application is built as a view with subviews. The design of the visualization framework leads to a tree structure. As every view has its controller, the view component tree is paralleled by a similar tree of controllers.

Models

The model is a different thing. For many applications, all subviews share one common model. For a large application, such a common model is often burdened with a lot of view support functionality. This gives raise to the question: Is it possible to give an application model a structure that is similar to the tree structure of the view?

The concise answer is that it is possible, but not always necessary to structure an application model. When we choose to structure a model, we use model components to create a tree-like structure.

The Menu of a View

All three elements of the MVC triad cooperate to bring up a context menu. The controller detects the mouse click that it has to interpret as a menu request. The request is translated into what is called the yellow button activity. That activity sends the message getMenu: to the view. Most views forward the menu request to the model. The model is expected to create a menu that reflects the current model state. The controller displays the menu and processes the selected option. Most controllers send a message to the model that gives the model a chance to process the selection. A controller has the final responsibility to process all menu options that are not processed by the model.

Some views prepare an empty CustomMenu. The view and all model components can add options to such a menu.