Understanding MVC Elements

The MVC pattern is composed of three subsystems as indicated by the name: the model, the view, and the controller. In the next few sections, we'll look at each of these elements. Then we'll look at how they work together. When referring to the use of a model, a view, and a controller together, we call this grouping the MVC triad.

The Model

The model is the element that stores the data that is used in the MVC triad. The model can be as simple as storing one primitive value such as a string, yet it can also store extremely complex structures of data. The defining aspects of the model are that it acts as a storehouse for data and that it exists independently of the view and the controller. The model should never have a reference to the view or the controller. This is absolutely essential to the functioning of the MVC pattern because the model's independence is what creates the flexibility in the MVC pattern. If a model has a reference to a view or controller then it is tightly coupled, and it is specific to a particular type of controller and/or view. However, if the model communicates without having to have references to specific types of controllers or views then it can be used with many different types of controllers and views. We'll see how a model can interact within the MVC triad in "The Relationships Between Subsystems" section, later in this chapter.

The View

The view is the visual display portion of the user interface subsystem. The view uses the data from the model to draw itself. A view can consist of an animation, a user input form, a chart, buttons, an audio player, or any sort of user interface elements you might need in your application.

The key to understanding the view is to understand that it consists only of the visual elements and the logic necessary to read the model data and use it as required by the user interface.

The Controller

The controller is the subsystem that is responsible for taking input (user input, for example) and updating the model and view as necessary. For example, if the model needs to update data, the controller is responsible for that action.

The Relationships between Elements

Each of the elements has a specific type of relationship with the other elements. The model element must always remain independent of the view and the controller. This means that the model cannot know about any other element. This does not mean that the model does not communicate with the other elements. A model can broadcast messages when the data changes. However, what's important is that the model merely broadcasts the message without having to know who is listening. This use of events allows the model to be decoupled from the other subsystems, allowing for greater flexibility.

The view always knows about the model. The view interacts with the model in two ways: It listens for update messages, and it reads from the model. The view never writes to the model. Every view keeps a reference to its model. Because a view knows about its model but a model doesn't know about a view, a single model can act as the model for many views.

The controller also knows about the model. The controller is responsible for updating the model when necessary based on user input or system events.

The relationship between the controller and the view is very tightly coupled. Although it is possible to have a controller that uses several views, it is far more common that the relationship between view and controller is one-to-one. The view contains all the user interface elements through which the user interacts. Yet the controller is the element that responds to user input. In many, if not most, ActionScript applications, the view and the controller are one class. This variation of the MVC pattern is often called a Document View implementation of MVC.

The most important key to the MVC pattern is that the model must be an independent object that does not have a reference to the view or controller. The view updates and redraws itself based on changes to the model.