Introduction

• Model-View-Controller (MVC)is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data. That is when we want to use the same data but rendered on different types of devices like PC, mobile, pad etc. Each of these devices will be required to render the same content in a different format.
• The MVC pattern hinges on a clean separation of objects into one of three categories
  • models for maintaining data,
  • views for displaying all or a portion of the data,
  • and controllers for handling events that affect the model or view(s).
• Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design.

How It Works

The MVC abstraction can be graphically represented as follows.

• Events typically cause a controller to change a model, or view, or both.
• Whenever a controller changes a model’s data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.

A Example

We explain the MVC pattern with the help of a simple spinner component which consists of a text field and two arrow buttons that can be used to increment or decrement a numeric value shown in the text field. We currently do not have an element type that can directly represent a spinner component, but it easy is to synthesize a spinner using existing element types.

• The spinner’s data is held in a model that is shared with the text field.
• The text field provides a view of the spinner’s current value.
• Each button in the spinner is an event source; that spawns an action event every time it is clicked.
• The buttons receive action events and route them to an action listener that eventually handles that event.
• Recall that a trampoline is a predefined action listener that simply delegates action handling to another listener.
• Depending on the source of the event, the ultimate action listener either increments or decrements the value held in the model — The action listener is an example of a controller. The trampolines that initially receive the action events fired by the arrow buttons are also controllers — However, instead of modifying the spinner’s model directly, they delegate the task to a separate controller (action listener).