• Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

MVC

Before we talk about MVP, let’s look at MVC. MVC is an architecture recommended by Apple. The official Apple documentation explains MVC as follows:

The Model-View-Controller (MVC) design pattern divides objects in an application into three roles: model, view, or controller. A pattern defines not only the roles that objects play in an application, but also how objects communicate with each other. Each of these three types of objects is separated from and communicates with other types of objects through abstract boundaries. A collection of objects of a particular MVC type in an application is sometimes called a layer, such as the Model Layer.

MVC is at the heart of good design for Cocoa applications. The benefits of adopting this model are numerous. Many objects in these applications tend to be easier to reuse, and their interfaces tend to be better defined. Applications with AN MVC design are also easier to scale than other applications. In addition, many Cocoa technologies and architectures are based on MVC and require your custom objects to play one of the MVC roles.

  • Model Objects

Model objects encapsulate application-specific data and define the logic and calculations that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. One model object can have a one-to-many relationship with other model objects, so sometimes the model layer of an application is actually one or more object diagrams. Most of the data that is part of the persistent state of the application (whether the persistent state is stored in a file or a database) should reside in model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a particular problem domain, they can be reused in similar problem domains. Ideally, the model object should not have an explicit connection to the view object that displays its data and allow the user to edit that data. It should not be about user interface and display issues.

Communication: User actions in the view layer that create or modify data communicate through controller objects and cause model objects to be created or updated. When the model object changes (for example, when new data is received over a network connection), it notifies the controller object, which updates the corresponding view object.

  • View Objects

View objects are objects that can be seen by the user in the application. View objects know how to draw themselves and can respond to user actions. One of the primary uses of the view object is to display data from the application model object and enable editing of that data. However, view objects are often decoupled from model objects in MVC applications. Because you typically reuse and reconfigure them, view objects provide consistency across applications. Both UIKit and AppKit frameworks provide a collection of view classes, and Interface Builder provides dozens of view objects in its library.

Communication: View objects learn about changes in model data through the application’s controller objects and communicate user-initiated changes (for example, through text entered in a text field by the controller objects) to the application’s model objects.

  • Controller Objects

The controller object acts as an intermediary between one or more view objects of the application and one or more model objects. Thus, the controller object is a conduit through which the view object learns about changes in the model object and vice versa. Controller objects can also perform setup and coordination tasks for applications and manage the life cycles of other objects.

Communication: Controller objects interpret user actions performed in view objects and communicate new or changed data to the model layer. When the model object changes, the controller object passes the new model data to the view objects so that they can display it.

However, in real development, two problems are commonly encountered:

  • VC is overweight
  • Coupling problem

In real development, it is common to pass the model into the VIEW in VC to generate the view, and change the model inside the view, which leads to coupling problems. And in VC, there are often many heavy UI, long-winded business logic, a very long network layer, uncomfortable agents and so on make VC become bloated. What we want is to have high cohesion, low coupling, which means whoever does what they do, and let VC do only one task — build dependencies.

MVP

In the MVP

  • Migrating business logic originally written in the ViewController layer to Presenter solves the problem of excessive Controller layer responsibilities.

  • The Presenter layer deals with the business logic, while the ViewController layer implements the interface provided by the Presenter to update the View, thus decoupling the business logic from the UI.

Process:

The user clicks on View -> View responds to events -> passes events to Presenter via proxy -> initiates a network request to update Model- > Finishes processing data -> Proxy or notifying the View(View or Controller)- > Changes View style -> Done