MVC Design Pattern in Cocoa
- High level pattern that classifies objects based on the roles they play in an application
- Its a compound design pattern and comprises of several elemental design pattern
- e.g of mvc pattern in Cocoa can be found in Cocoa Bindings, Cocoa Document Architecture, Scriptability etc
MVC Pattern is divided into objects
- Model Objects
- View Objects
- Controller Objects
If developers are adhering to this Design pattern and are creating their custom classes, the custom classes must fall into one of the 3 categories (model, view or controller)
- Holds data and defines logic that manipulates that data
- All persistent data must reside in models.
- Model objects should not be concerned with interfaces and presentation issues.
- Knows how to display the data and allows the users to edit it
- Views should not be responsible for storing the data that it is displaying
- Caching Data in View Objects is an exception for performance reasons.
- Views can be responsible for rendering a part of the model objects or the whole model object
- A large number of view objects can be found in AppKit Framework
- Acts as an intermediary between the applications view and model objects
- Acts as a conduit through which the view objects knows about the change in the model objects
- Controllers are also responsible for managing the lifecycle of other objects
Combining Roles in MVC Design Pattern
- Fulfills the role of both the controller and the view
- It owns the interface (views).
- Main responsibility is to manage the interface and communicate with the models.
- Owns the model.
- Main responsibility is to manage the model and communicate its changes to view objects
Types of Controller Objects
- Inherits from NSController class
- Used in Cocoa Bindings
- Some ready to use Mediating Controller classes are
- Facilitates, Mediates the flow of data between view and model objects
- Provides services such as responding to delegation messages
- Responding to action messages
- Managing the lifecycle of objects (Windows, View Objects, Instance variables, Mediating Controllers etc)
- Establishing connection between objects
- Example of Co-ordinating controllers are
The pattern as a (Composite, Strategy and Observer ) design pattern
- View Objects are a composite of nested views (view hierarchy)
- View objects confines itself to maintaining its visual aspect and delegates all the decision about the application specific meaning to the controller
- Model objects keeps the view objects apprised/advised about the changes in its state.
- For mediating controller, use an instance of NSObjectController, NSArrayController, NSTreeController rather than implementing all the functionalities in a NSObject subclass
- Keep the roles separated for maximum reusability
- In case you are planning to merge roles, then pick the predominant role for a class and use categories to extend the class to play other roles
- Although it is possible to have views directly observe the properties of model objects, it is not a best practice. Avoid the temptation. A view should always go through a mediating controller to learn about the changes in a model object
- A view class should not depend on a model class (If this is unavoidable, reduce the dependency)
- A model class should not depend on anything other than model classes
- A mediating controller should not depend on model classes, view classes or co-ordinating controllers.