An Objective-C/Perl Bridge

The MVC (Model-View-Controller) design pattern

MVC, the Model-View-Controller design pattern, is very often used in Cocoa programming. In it, you divide your classes into three distinct categories that reflect the role they play in your application.


Model classes represent data, and the intrinsic operations that can be performed on that data. They provide accessor methods that other class types will use to work with them, and know nothing of how they are being displayed, or of user actions or other events.

Commonly used classes in the model layer are the collection classes - NSArray, NSDictionary, NSSet, and others, along with their mutable variants. NSObject subclasses are also often used, with properties that contain one or more collection objects, forming an aggregate object.


View classes handle the interface that the user interacts with. Windows, buttons, menus, etc. are defined as view classes. View classes play a dual role: They display data retrieved from a model class, and they transform "primitive" user actions such as mouse clicks and button presses into the higher-level events that are sent to controllers.

Most of Cocoa's AppKit is concerned with view classes and classes that closely interact with them. It is also quite common for view classes to have nothing at all to do with a desktop GUI, such as the view classes that are used to produce HTML output and accept form input for a web-based application.


Controller classes act as intermediaries between view and model classes. In response to an event generated by a view object, a controller object might call a model object's methods to change the model's data. After doing so, it might also instruct one or more view objects that display information from the model to refresh themselves. It is also common for a model object to use an NSNotification object to inform any interested observers that it has been modified.

Controllers can also be subdivided into view-controller and model-controller subcategories to more accurately reflect the role they play. The NSController subclasses used in Cocoa Bindings, for example, can be thought of as view-controllers. An NSDocument subclass used in a document-based application might be thought of as a model-controller, depending on whether it directly works with document data.

See also

The Model-View-Controller Design Pattern


the model-view-controller (MVC) design pattern