Figure 4.1. MVC component diagram

A component diagram has been used to describe this pattern. Each of the three parts of the MVC pattern is a component, that can contain many classes and interfaces.

Implementing the MVC pattern requires the following components:

Model – This component contains one or more classes and interfaces that are responsible for maintaining the data model. The state of the model is kept in attributes and the implementation of methods. To be able to notify view components of any change in the model, the model keeps a reference to each registered view (there can be more than one at the same time). When a change occurs, every view component that has registered should be notified.

View – The classes and interfaces of the view provide a representation of the data in the model component. The view may consist of visual GUI components, but is not required to. A view must be registered with the model to be notified of changes to the model data. When a notification of such a change is received, the view component is responsible for determining if and how to represent this change.

The view component also keeps a reference to the model to retrieve data from the model, but it can only retrieve information, not change it. The view can also be used to render the controller, but requests for change are always forwarded to a controller component; so the view needs to keep a reference to one or more controllers.

Controller – This component manages changes to the model. It keeps a reference to the model component who is responsible for carrying out the change, whereas the controller calls one or more update methods. The requests for change may come from a view component.

Benefits and Drawbacks

MVC provides an excellent way to make an element that is flexible and adaptable to a variety of new situations. The flexibility can be used both statically and dynamically. New view or controller classes can be added to the application (static), and view or controller objects can be changed in the application at runtime.

Usually, the greatest challenge for MVC is to determine the true base representation; to define a suitable set of interfaces among model, view, and controller. An MVC element is often developed to satisfy a specific set of needs, like most software, so vision and careful analysis are required in order to implement the element so that you don’t impose application-specific restrictions on it.

Pattern Variants

MVC variants often revolve around different implementation choices for the view.

Model push versus view pull – You can implement MVC in one of two ways the model can send updates to its view (or views), or a view can retrieve information as needed from the model. The choice affects how the relationship is implemented in the system.

Multiple view targets – A model can provide information to more than one view. This is particularly useful for some GUI implementations, since the same data must sometimes drive multiple representations.

142