Internet & Web Application

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

อธิบายเรื่อง Model / View / Controller ไว้ได้ดี

————————————————————————————————————-

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.

MVC pattern

Figure 1. Model / View / Controller pattern.

back to top
One of the goals of the MVC pattern is to enable the combination of a single Model with multiple Views and Controllers, as shown in Figure 2. The MVC pattern ensures that the Views are kept synchronized as can be seen from the following example. One of the Controllers recognizes a valid command from the user’s input. The Controller invokes the corresponding method on the Model. The Model verifies that the operation is compatible with the current state, executes it and changes the state correspondingly. The state change triggers an event that the Model multicasts to each View.

MVC pattern with multiples Views and Controllers

Figure 2. MVC pattern with multiple Views and Controllers.

back to top
To support multiple Views and Controllers, dependencies must be kept in a minimum. (A is said to depend on B when the code of A embeds knowledge about B.) This leads to the following rules (see Figure 3 for allowed dependencies):

  • 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.

Dependencies between the roles of the MVC pattern

Figure 3. Allowed dependencies in the MVC pattern.

back to top
Another precondition to support multiple Views and Controllers is to keep interactions to a minimum. In particular a Controller must never directly affect the rendering of its associated View. Instead, user input must make a complete round trip through the Model before its effects become visible in the View. This rule guarantees that a state change updates all Views and the Views remain synchronized. Often implementations with a single Controller violate this rule because of sloppy thinking: “I already know that this state change will occur, and therefore don’t need to wait for the Model to tell me about it”. This is wrong for two reasons:

  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.

Server-centric function placement

Figure 5: Server-centric function placement.

back to top

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.

Function placement with replication model

Figure 6: Function placement with replicated model.

back to top
References
[KrPo88] Glenn E. Krasner, Stephen T. Pope, “A cookbook for using the model-view controller user interface paradigm in Smalltalk-80”, Journal of Object-Oriented Programming, Vol.1 No. 3, August / September 1988.
[PPR01] Portland Pattern Repository’s Wiki, page “Model View Controller”, accessed August 2001.
Advertisements
มาตรฐาน

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s