MVC - Application design in swing like framework (i.e. nextapp Echo3)

Figure1. A Common MVC Implementation

 

 Interaction Between MVC Components

 

Once the model, view, and controller objects are instantiated, the following occurs:

1. The view registers as a listener on the model. Any changes to the underlying data of the model immediately result in a broadcast change notification, which the view receives. This is an example of the push model described earlier. Note that the model is not aware of the view or the controller -- it simply broadcasts change notifications to all interested listeners.
2. The controller is bound to the view. This typically means that any user actions that are performed on the view will invoke a registered listener method in the controller class.
3. The controller is given a reference to the underlying model.

Once a user interacts with the view, the following actions occur:

1. The view recognizes that a GUI action -- for example, pushing a button or dragging a scroll bar -- has occurred, using a listener method that is registered to be called when such an action occurs.
2. The view calls the appropriate method on the controller.
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action(accessing to the backend service for instance)
4. If the model has been altered, it notifies interested listeners, such as the view, of the change. In some architectures, the controller may also be responsible for updating the view. This is common in Java technology-based enterprise applications.

Figure 2 shows this interaction in more detail.

Figure 2. A Java SE Application Using MVC

The model does not carry a reference to the view but instead uses an event-notification model to notify interested parties of a change. 

One of the consequences of this powerful design is that the many views can have the same underlying model. When a change in the data model occurs, each view is notified by a property change event and can update itself accordingly. 

For example, Figure 3 shows two views that use the same data model.

Figure 3. Multiple Views Using the Same Model

Modifying the MVC Design

 

A more recent implementation of the MVC design places the controller between the model and the view. This design, which is common in the Apple Cocoa framework, is shown in Figure 4.

Figure 4. An MVC Design Placing the Controller Between the Model and the View

The primary difference between this design and the more traditional version of MVC is that the notifications of state changes in model objects are communicated to the view through the controller. (that means the controller will be the model changes listener instead of the views component, to decouple better the model from the view)

Hence, the controller mediates the flow of data between model and view objects in both directions. View objects, as always, use the controller to translate user actions into property updates on the model. 

In addition, changes in model state are communicated to view objects through an application's controller objects.

Thus, when all three components are instantiated, the view and the model will both register with the controller. Once a user interacts with the view, the events are nearly identical:

1. The view recognizes that a GUI action -- for example, pushing a button or dragging a scroll bar -- has occurred, using a listener method that is registered to be called when such an action occurs.(as the old design)
2. The view calls the appropriate method on the controller.(as the old design)
3. The controller accesses the model, possibly updating it in a way appropriate to the user's action.(as the old design)
4. If the model has been altered, it notifies interested listeners of the change. However, in this case, the change is sent to the controller.

Why adopt this design? Using this modified MVC helps to more completely decouple the model from the view. In this case, the controller can dictate the model properties that it expects to find in one or more models registered with the controller. In addition, it can also provide the methods that effect the model's property changes for one or more views that are registered with it.

The Hierarchical MVC

Why isn’t this enough ?
 
The MVC is an excellent basis on which to build a graphical application,however, as if stands it is not a complete solution. The basic problem is that,in general, if you tried to use just one Controller, one Model and one View for your whole application, the result would be unmanageable. 

For example, let us imagine that we were trying to build an email tool. 
With one single model we might be trying to represent;

· Read, unread, deleted, pending emails
· Address books
· Emails under construction
· The POP or SMTP configurations
· The sender’s profile (eg. name, return email etc.)
· Attachments, signatures etc.
 
The resulting model, even if it referenced other objects, would be
unmanageable. What is required is the ability to break the application down into its constituent elements. 

One way in which we could do this would be to have separate
parts of the architecture deal with the address book, the sender element,reading mail, creating mail etc. This is where the hierarchical MVC comes in.

The H-MVC

The Hierarchical MVC framework (referred to in this column as h-MVC) is a modification of the basic MVC framework that encourages the decomposition of an application, or client, in an n-tier architecture. It is of course not the only way in which such a GUI oriented application (or client) can be decomposed, but some of the benefits of this approach include.

· Building on a well established existing framework (the MVC)
· Standardizing structures and interactions between different aspects of the application – leading to greater understanding between developers.
· Simplifying code maintenance code as each aspect can be developed,modified or updated separately.

The H-MVC Details

The hierarchical MVC (h-MVC) breaks the client part of an application whether a stand alone application or part of an n-tier system) down into separate MVC triads. 

Each MVC is then responsible for one aspect of the client.
Between the MVCs, well defined interfaces exist to allow information and behaviour-oriented requests to flow. These interfaces are supported by links between the controllers. 

The rationale behind this is that the controllers are
responsible for determining the flow-of-control within an MVC triad.Therefore, if one MVC triad needs to communicate with another MVC triad,then it is the controllers that should be responsible for this. 

This in turn meansthat the links between one MVC triad and another will necessarily be maintained by the controllers.

In this view we are applying OO principles to the design and implementation of the client. 

That is each MVC triad has :
· A particular responsibility
· Clearly defined interfaces to other MVC’s


Layered Application
 
The following (simple) example application will be used to illustrate the ideas behind the h-MVC. This application allows a user to input some simple search criteria in the name, age and sex fields. These can then run the search, the results of which are presented in the search results view. 
 

 
 Figure 2: The Search Application

The application is actually constructed using 3 MVC triads. The first triad represents the overall frame, the second triad deals with the search criteria,while the third triad deals with presenting the results of the search. This is illustrated in figure 3.




Figure 3: The MVC structure of the Search Application


The hierarchy represented by the links between the controllers in the three MVC triads is illustrated in figure 4.




Figure 4: The classes in the search application



Figure 6: The relationships between the search application classes and the MVC framework classes