Understanding the Model-View-Controller Paradigm

The StyledTextArea control conforms to the Model-View-Controller (MVC) design pattern. This section therefore starts with an overview of this design pattern, including its objectives.

The MVC pattern was the central concept behind the Smalltalk-80 user interface. At that time the term pattern had not been used. Instead, it was called the MVC paradigm.

Note

You can find a paper on the MVC paradigm by Steve Burbeck, "Applications Programming in Smalltalk-80: How to Use Model-View- Controller (MVC)," at http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html.

The MVC pattern consists of three kinds of main classes: Model, View, and Controller. The Model represents the application object or data. The View displays the model, and the Controller takes care of the user interface interaction with the user input. Prior to the MVC pattern, these three parts existed in one class, making the application inflexible and difficult to reuse. Figure 1-4 shows the MVC pattern component.

Figure 1-4: The MVC pattern

The MVC pattern loosens the coupling between views and models. The model simply encapsulates the application object. It does not know anything about the view. The view, on the other hand, is the visual representation of the model and depends on the model. The view has a reference to the instance of the model and so does the controller.

To understand the MVC pattern better, consider a Microsoft Excel spreadsheet in which the data can be represented using a pie chart, a line diagram, and so on. The pie chart and the line diagram are the views displaying the same piece of data. The controller gives commands to both the model and the view according to the user input. For example, in a text area component, when the user types a character, the controller invokes a method in the model to update the data and send a command to the view to update the visual representation accordingly.

In the passive model, the model does not do anything other than take care of the data. In another variant of the MVC pattern, however, an Observer pattern often exists between the model and the view. When some state in the model changes, the model notifies the view of the change. The view in turn can update itself so that the change is reflected.

Unlike the relationship between the model and the view, the view and the controller have a more intimate relationship. A view is normally passed a reference to the controller object and can access some of the variables in the controller.

In an application, often there is only one view for each MVC triad. However, it is not uncommon to have multiple views for the same model. The StyledTextArea component you are building, for instance, employs two views. You will see the architecture in the following section.

Note

I base this StyledTextArea control on the MVC pattern to promote code reuse and to increase flexibility. In addition, separating the code into smaller classes makes the code more manageable. However, the MVC pattern does not come without a "side effect." It does make it harder for the user of the component to use it. Instead of having to deal with one class, now there are three main classes: the Model, the View, and the Controller. To minimize this side effect, you hide the Model and View classes from the user. The user only sees one class: StyledTextArea, which is the controller in the component.