---

The MVC Design Pattern

Model-View-Controller (MVC) is a design pattern that was derived from Smalltalk-80. It proposes three types of objects in an application, separated by abstract boundaries and communicating with each other across those boundaries, as illustrated in Figure 1-2. This is the design pattern behind many designs for object-oriented programs. This design pattern aids in the development of maintainable, extensible, and understandable systems.

In this section:

Model Objects
View Objects
Controller Objects
Hybrid Models

Model Objects

This type of object represents special knowledge and expertise. Model objects hold data and define the logic that manipulates that data. For example, suppose you have a customer object, a common object in business applications, that holds all of the salient facts about a customer, including the customer’s name, date of birth, and phone number. That object would be a model object because it represents the data your applications manipulates, and has access to methods that can access and distribute that information. A more specialized model might be one in a meteorological system called Front; objects of this type would contain the data and intelligence to represent weather fronts. Model objects are not directly accessed by the user of the application. They are often reusable, distributed, persistent, and portable to a variety of platforms.

View Objects

A view object represents something visible on the user interface (a window or a button, for example). A view object is “ignorant” of the source of the data it displays. The Application Kit, one of the frameworks that Cocoa is composed of, usually provides all the basic view objects you need: windows, text fields, scroll views, buttons, browsers, and so on. But you might want to create your own view objects to show or represent your data in a novel way (for example, a graph view). You can also group view objects within a window in novel ways specific to an application. View objects tend to be very reusable and so provide consistency between applications.

Controller Objects

Acting as mediators between model objects and view objects in an application are controller objects. Controller objects communicate data back and forth between the model and view objects. A controller object, for example, could mediate the transfer of a street address (from the customer model object) to a visible text field on a window (the view object). It also performs all the chores specific to the application it is part of. Since what a controller does is very specific to an application, it is generally not reusable even though it often comprises much of an application’s code. (This last statement does not mean, however, that controller objects cannot be reused; with a good design, they can.) Because of the controller’s central, mediating role, model objects need not know about the state and events of the user interface, and view objects need not know about the programmatic interfaces of the model objects. You can even make your view and model objects available to other developers from a palette in Interface Builder.

Hybrid Models

MVC, strictly observed, is not always the best solution. Sometimes it’s best to combine roles. For instance, in a graphics-intensive application, such as an arcade game, you might have several view objects that merge the roles of view and model. In some applications, especially simple ones, you can combine the roles of controller and model; these objects join the special data structures and logic of model objects with the controller’s hooks to the interface.

---