MODEL-VIEW-CONTROLLER(MVC)

Model-View-Controller(MVC) design is a high-level which concerns itself with the global architecture of an application and classifies objects according to the general roles they play in an application.Object-oriented programs benefit in several ways by adapting the MVC design pattern for their designs. Many objects in these programs tend to be more reusable and their interfaces tend to be better defined.

It mainly consists of three layers:

1)Model Layer

2)View Layer

3)Controller Layer

1) Model Layer:

Model layer consists of following components:

Network Code: This code is useful for network communication for the entire app

Persistence Code: This code is used to implement the core data or simply by saving an NSData blob directly to disk.

Parsing Code: Any objects that parse network responses and the like should be included in the Model layer as well.

Model objects encapsulate data and basic behaviours.They hold an application’s data and define the logic that manipulates the 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 should reside in the model objects once the data is loaded into the application.

Ideally, a model object has no explicit connection to the user interface used to present and edit it. A model object should not be concerned with interface and presentation issues.

2) View Layer:

When a user interacts with your app, they are interacting with the view layer. The view is considered the “dumb” part of your app, since it shouldn’t contain any business logic. In code terms, you’ll normally see:

UIView subclasses: These range from a basic UIView to complex custom UI controls.

UIViewController: A UIViewController is strongly coupled with its own root UIView and its different cycles (LoadView,ViewDidLoad).

Animations and UIViewController transitions.

Classes that are part of UIKIT/APPKIT, Core Animation and Core Graphics

Use the following as a checklist when inspecting your view layer:

Does it interact with the model layer?

Does it contain any business logic?

Does it try to do anything not related to UI?

If we write these classes well, we can almost always reuse them.

View objects present information to the user.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.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 Cocoa, the AppKit framework defines a large number of view objects and provides many of them in the Interface Builder library. By reusing the AppKit’s view objects, such as NSButton objects, you guarantee that buttons in your application behave just like buttons in any other Cocoa application, assuring a high level of consistency in appearance and behaviour across applications.

View should ensure it is displaying the model correctly. Consequently, it usually needs to know about changes to the model. Because model objects should not be tied to specific view objects, they need a generic way of indicating that they have changed.

3) Controller Layer:

The Controller Layer is the least reusable part of your app, because it involves your domain-specific rules. Controller objects tie the model to the view.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 a typical Cocoa 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.

Based on this same user input, some controller objects might also tell a view object to change an aspect of its appearance or behaviour, 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.

MVC As A Compound Design Pattern:

Model-View-Controller is a design pattern that is composed of several more basic design patterns.These basic patterns work together to define the functional separation and paths of communication that are characteristic of an MVC application.However, the traditional notion of MVC assigns a set of basic patterns different from those that Cocoa assigns. The difference primarily lies in the roles given to the controller and view objects of an application.

MVC is made up of the Composite, Strategy, and Observer patterns.

Composite: The view objects in an application are actually a composite of nested views that work together in a coordinated fashion. These display components range from a window to compound views, such as a table view, to individual views, such as buttons. User input and display can take place at any level of the composite structure

Strategy: A controller object implements the strategy for one or more view objects. The view object confines itself to maintaining its visual aspects, and it delegates to the controller all decisions about the application-specific meaning of the interface behaviour.

Observer: A model object keeps interested objects in an application — usually view objects — advised of changes in its state.

The user manipulates a view at some level of the composite structure and, as a result, an event is generated. A controller object receives the event and interprets it in an application-specific way — that is, it applies a strategy. This strategy can be to request a model object to change its state or to request a view object (at some level of the composite structure) to change its behaviour or appearance. The model object, in turn, notifies all objects who have registered as observers when its state changes; if the observer is a view object, it may update its appearance accordingly.

Traditional version of MVC as a compound pattern

The cocoa version of MVC as a compound pattern has some similarities to the traditional version, and in fact it is quite possible to construct a working application.By using the bindings technology, you can easily create a Cocoa MVC application whose views directly observe model objects to receive notifications of state changes. However, there is a theoretical problem with this design. View objects and model objects should be the most reusable objects in an application. View objects represent the “look and feel” of an operating system and the applications that system supports; consistency in appearance and behaviour is essential, and that requires highly reusable objects. Model objects by definition encapsulate the data associated with a problem domain and perform operations on that data. Design-wise, it’s best to keep model and view objects separate from each other, because that enhances their reusability.

Cocoa version of MVC as a compound design pattern

The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application. In addition, view objects incorporate the Command pattern through their implementation of the target-action mechanism.

Mediating controllers derive from concrete subclasses of NSController, and these classes, besides implementing the Mediator pattern, offer many features that applications should take advantage of, such as the management of selections and placeholder values. And if you opt not to use the bindings technology, your view object could use a mechanism such as the Cocoa notification centre to receive notifications from a model object. But this would require you to create a custom view subclass to add the knowledge of the notifications posted by the model object.

Coordinating controller as the owner of a nib file.

In a well-designed Cocoa MVC application, coordinating controller objects often own mediating controllers, which are archived in nib files.

Design Guidelines For MVC Applications:

Although you can combine MVC roles in an object, the best overall strategy is to keep the separation between roles. This separation enhances the reusability of objects and the extensibility of the program they’re used in. If you are going to merge MVC roles in a class, pick a predominant role for that class and then use categories in the same implementation file to extend the class to play other roles.

A goal of a well-designed MVC application should be to use as many objects as possible that are reusable. In particular, view objects and model objects should be highly reusable. Application-specific behaviour 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 an 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 view class shouldn’t have to depend on a mediating controller class.

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

A mediating controller class shouldn’t depend on a model class (although, like views, this may be necessary if it’s a custom controller class).