MVC (Model-View-Controller) is perhaps the oldest and most widely used software pattern and dates back to the late 1970s. It's goal has been to prevent data (models) from explicitly knowing about all the data visualizations that depend on it and also to decouple the actions that are needed to work with and modify the data located in the model from the model itself. By centralizing data in one source, redundancy had been eliminated. A Controller object was introduced to coordinate the modifications that are necessary for the data located in the model.

Although there are many deviations, the MVC pattern basically consists of three collaborating roles. The first is called the model, which is responsible for storing data. The second role is the view and takes care of the visualization of any data located in the model. The third role is the controller. Its responsibility is to facilitate manipulation of the data in the model by propagating user events to it and to propagate model changes to all dependent views. These three roles logically participate in the Observer pattern as well: view objects observe a model, model objects observe a controller and controller objects observe both model and view.

Figure 4.2. MVC Roles

The Tensegrity Graph API implements the MVC pattern by supporting multiple views for a single Graph model. The controller serves an administrative role by notifying all VisualGraph views about any model changes which have occurred. Normally, model changes lead to a situation where one or more views might not reflect the current state of their model. The MVC pattern decouples our Graph models from the views by having a GraphController act as a mediator. This controller notifies all views when the model changes and these views subsequently refresh themselves, if necessary, by requesting data from their associated Graph model.

This is not the end of the story, however. Within the Tensegrity Graph API, a controller cannot be used to exclusively receive and propagate user events directly to a model only. This is because a GraphView is a manipulatable, persistable object in its own right. In such a MVC scenario, where a view contains unique attributes not found it its model, the view essentially “acts” like model itself. For this reason, both models and views must be capable of directly receiving user events.

The following figure illustrates these two scenarios better: Manipulations that are made to a model are propagated to a view (blue edges) and manipulations that are made to a view are propagated to its model (red edges). Notice that user events (commands) may be directed towards the model or towards the view.

Figure 4.3. MVC in the Tensegrity Framework