Traditional MVC and MVC in iOS development

Keep it short and clear, let’s go straight away to see the diagrams for traditional MVC and MVC in iOS.

In traditional MVC, view objects may register the model object’s state change events by adopting Subject-Observer design pattern, view objects will get notified once its interested model object’s state changes.

While in iOS, the direct interaction between view objects and models is something we should strive to avoid. A view object should always go through a controller object to learn about changes in an model object.

Well, that’s it. The above is the main thing i would like to talk in this article, but you can read on if you want to get a little bit more detail.

Model-View-Controller is a very high-level architectural design pattern, which considers there to be three types of objects: model objects, view objects, and controller objects. It defines the roles that these types of objects play in the application and their lines of communication.

Model objects

The model is the central component of the pattern. It represents special knowledge and expertise and expresses the application’s behavior in terms of the problem domain. They hold an application’s data and define the logic that manipulates that data. A well-designed MVC application has all its important data encapsulated in model objects. Any data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects once the data is loaded into the application. Because they represent knowledge and expertise related to a specific problem domain, they tend to be reusable.

Ideally, a model object has no explicit connection to the user interface used to present and edit it. For example, if you have a model object that represents a person (say you are writing an address book), you might want to store a birthdate. That’s a good thing to store in your Person model object. However, storing a date format string or other information on how that date is to be presented is probably better off somewhere else.

View objects

A view object knows how to display, and might allow users to edit, the data from the application’s model. The view should not be responsible for storing the data it is displaying. (This does not mean the view never actually stores data it’s displaying, of course. A view can cache data or do similar tricks for performance reasons). A view object can be in charge of displaying just one part of a model object, or a whole model object, or even many different model objects. Views come in many different varieties.

View objects tend to be reusable and configurable, and they provide consistency between applications. In iOS, the UIKit framework defines a large number of view objects and provides many of them in the Interface Builder library. By reusing the UIKit’s view objects, such as UIButton objects, you guarantee that buttons in your application behave just like buttons in any other iOS application, assuring a high level of consistency in appearance and behavior across applications.

Controller objects

A controller object acts as the intermediary between the application’s view objects and its model objects. Controllers are often in charge of making sure the views have access to the model objects they need to display and act as the conduit through which views learn about changes to the model. Controller objects can also perform set-up and coordinating tasks for an application and manage the life cycles of other objects.

In an iOS MVC design, when users enter a value or indicate a choice through a view object, that value or choice is communicated to a controller object. The controller object might interpret the user input in some application-specific way and then either may tell a model object what to do with this input — for example, “add a new value” or “delete the current record” — or it may have the model object reflect a changed value in one of its properties. Based on this same user input, some controller objects might also tell a view object to change an aspect of its appearance or behavior, such as telling a button to disable itself. Conversely, when a model object changes — say, a new data source is accessed — the model object usually communicates that change to a controller object, which then requests one or more view objects to update themselves accordingly.

Interactions

In addition to dividing the application into three kinds of components, the model–view–controller design defines the interactions between them.

• A model stores data that is retrieved according to commands from the controller and displayed in the view.
• A view generates new output to the user based on changes in the model.
• It can also send commands to its associated view to change the view’s presentation of the model

Design Guidelines for MVC in IOS development

The following guidelines apply to Model-View-Controller considerations in the design of applications:

• A goal of a well-designed MVC application should be to use as many objects as possible that are (theoretically, at least) reusable. In particular, view objects and model objects should be highly reusable. Application-specific behavior is frequently concentrated as much as possible in controller objects.
• Although it is possible to have views directly observe models to detect changes in state, it is best not to do so. A view object should always go through a mediating controller object to learn about changes in a model object.
• Strive to limit code dependency in the classes of your application. The greater the dependency a class has on another class, the less reusable it is. Specific recommendations vary by the MVC roles of the two classes involved:

-- A view class shouldn’t depend on a model class (although this may be unavoidable with some custom views).

-- A model class shouldn’t depend on anything other than other model classes.