Model-View-Controller
PGUI: Model-View-Controller

MVC Architecture

Model-view-controller (MVC) -architecture is a combination of design patterns that is especially suitable for GUI programming. A schematic of MVC is is shown in the figure:

Model-view-controller

As an example of a MVC application a simple Java-application for drawing diagrams is presented. The application will be further developed in the following material. See the complete example.

Model

The model is the information that the application is manipulating. This is the data representation on the real-world objects in which the user is interested.

In Java we can use the class java.util.Observable as a superclass of a model.

In our example application the model consists of nodes and connecting lines or connectors. The model is in class Diagram (Diagram.java).

The model notifies each view of the changes in the model data. Every time a node is created, moved or otherwise changed the diagram model calls two functions of the superclass (setChanged and notifyObservers): 

public class Diagram extends Observable
{
   ...
   // create a new node
   public Node createNode(String title, int x, int y)
   {
      Node n = new Node(title, x, y);
      nodes.add(n);
      setChanged();
      notifyObservers(this);
      return n;
   }

View

The view implements the visual display of the model. There can be several different views of the same model.

Anytime the model is changed, each view of the model is notified so that it can change the visual representation of the model on the screen.

A region of the screen that is no longer consistent with the model information is called damaged (or invalid). When notified of a change, the view will identify the changed parts of the display and report them to the windowing system as being damaged. The windowing system will then cause the damaged region to be redrawn (or updated). The view will do the redrawing.

In Java we can use interface java.util.Observer as a basis of the view. In addition the view class is usually also a user interface component, here a subclass of javax.swing.JPanel.

In our example, the view is implemented in class DiagramView (DiagramView.java).

The implementation of the view has been simplified so that a change in the model causes the entire view to be redrawn. This is accomplished in function update from the interface Observer: 

public class DiagramView extends JPanel implements Observer
{
   ...
   // the Observer function
   // called when model has been changed
   public void update(Observable o, Object arg) {
      if (arg instanceof Diagram.Node) {
         rcache.remove(arg);
      }
      repaint();
   }

The view decides on the actual visual representation on the diagram. The only thing in addition to the connections are the titles and the center point of the nodes. Thus the views needs to maintain some information of the bounding rectangles of the nodes (a map data structure rcache).

Notice that the view always waits for a notification about a change coming from the model before acting upon it.

Controller

The controller receives all the input events from the user and translates them into possible changes on the model.

In the example the controller receives the mouse and mouse motion events from the view, processes the interactions and changes the model. The canges will then be visible after the normal notification process has been made (model notifies the view).

The controller communicates with the view to determine whet object is being manipulated.

The separation of the controller and the view is based on the possibility of implementing several different controllers for one single view. This is not very common and the controller and the view are so tightly intertwined, that they are usually implemented in one class.

In out example the controller is an inner class of the view. It can be found in the class DiagramView (DiagramView.java)

Putting MVC together

There are many ways to connect the model, the views and the controllers together in the application. In our example we

  • create the model first,
  • create the view and put a reference to the model as a member variable of the view, and
  • create the controller inside the view.

A more finished application structure would connect creating MVC to the opening and creating of the documents.

Our demo application has one final class DiagramApp (DiagramApp.java).

Why separate model and view?

In a simple application it is empting to combine model, view and the controller into a single class or global variables. The are reasons not doing this:

  • The application may have multiple models and thus multiple views.

  • The model may have multiple views. The may be two views on the different parts of the model (split view), or two completely different views (graphical and list view).

  • The are software maintenance reasons. The model and the view implementation can be changed separately if the model interface has been fixed. The view can be changed and new views can be created without changing the model.

  • A complex software architecture is easier to implement with MVC. It is easier to understand and manage.

See also:
Diagram example