Model / View / Controller (MVC) pattern in a multi-device configuration

The Model / View / Controller (MVC) pattern is a well-known recipe for writing software that simultaneously provides different views of the same set of data. This pattern is widely used by programmers to structure traditional applications that run on a single device. Hence, it is a natural starting point for developing applications to be shared among multiple devices. There are several possibilities to extend the MVC pattern to a multi-device configuration, depending on where the different entities reside.

The MVC pattern for GUI libraries — background

The problem of how to give a user several different access paths to the same set of data simultaneously was addressed by the developers of Graphical User Interface (GUI) libraries [PPR01]. The Model / View / Controller (MVC) pattern was introduced in a Smalltalk GUI library and is a recipe of how to display the same data in several windows in different views [KrPo88]. The user can manipulate the data in any window and the other windows reflect the changes immediately.

The roles (participants) in the MVC pattern are:

• The Model encapsulates application state (data) and operations that modify that state. A model is meant to serve as a computational approximation or abstraction of some real-world process or system. For example the Model of a shopping cart of an e-commerce application contains the identity and number of purchased items and offers operations to add and remove items from the shopping cart.
  
  
• The View is responsible for presenting (rendering) the information contained in the Model in a particular output modality. For example a graphical View may render a shopping cart as a list of items and their number, plus a "remove" button next to each item.

  A View is an Observer of the Model (and therefore also depends on the Model). At initialization time the View registers with the Model to express its interest in any changes of the Model's state. Whenever the Model changes state it notifies the View by sending it an EventObject that contains the state change. The View then updates its rendering.
  

• The Controller accepts input from the user in a particular modality, interprets the input (the interpretation may depend on the View), and invokes the appropriate operation of the Model. For example when the Controller detects a mouse click event on the "remove" button of an item it invokes the remove operation on that item. Any state changes of operation effects on the Model are sent by the Model to the registered Views via events and EventObjects.

Figure 1.    Model / View / Controller pattern.

Figure 2.   MVC pattern with multiple Views and Controllers.

• The Model does not have any dependency on Views or Controllers.
• A View depends on its associated Model. It has to know the structure of the Model's state to render it.
• A View does not have a dependency on Controllers. Therefore several different Controllers can be associated with the same View.
• A Controller depends on its associated Model and View. The Model defines the operations the Controller can invoke and the View defines the context in which the Controller interprets the user input. This makes the Controller tightly coupled to the View.
  

Figure 3.  Allowed dependencies in the MVC pattern.

1. The Model can veto the operation for some reason. The operation will not occur.
2. Other Controllers concurrently invoke operations on the Model. Some other operation can slip in between, which fundamentally changes the rendering and makes any assumptions about it invalid.

It is impossible to extend such shortcut implementations with additional Controllers.

Extending the MVC pattern to multi-device applications

Although the MVC pattern was originally devised for GUIs running on a single machine, it is relatively straightforward to extend it in two dimensions. First, it can be extended to non-GUI interactions such as speech. Second, it can be extended to a distributed system, where some interfaces between Model, View and Controller cross the network. The placement of the Model, View and Controller then becomes crucial.

A server-centric placement puts the Model on a server. The mobile devices contain View / Controller pairs that interface to the Model via a network protocol, for example RPC. This approach has the benefit of relative simplicity. However, it is not suitable for environments where connectivity is not continuous, since as soon as there is a connectivity loss, the Controller and the View cannot interact with the Model.

Figure 5: Server-centric function placement.

A device-centric placement puts all three functions on each device: Model, View and Controller. The Model, which exists conceptually only in one instance, is replicated among the devices. A replication protocol keeps the Model replicas synchronized by propagating state changes in one replica to the other replicas.

Figure 6: Function placement with replicated model.

References