iOS design mode--mvc (Model-view-controller)

Modol View Controller (MVC) is one of the earliest and most successful reusable design patterns that were first successfully used in the Smaltalk program in the 70 's. Based on the MVC design pattern, the cocoa overall architecture can be divided into three subsystems: model, view, controller, which we can interpret as: data models, views, and controllers.

Modol View and controller roles

To understand the role of each subsystem in the MVC design pattern, we need to understand the functionality and behavior of an application. We know that an application usually needs to store data information, retrieve data information, and present the data to the user, while also allowing users to edit the data (adding and removing changes, etc.). Then the role of MVC is:

Model: provides independent data models for applications that do not depend on the view and controller subsystems.

View: renders data in a certain form like a user and allows the user to manipulate the data. The key to understanding view is to understand that the same data can be presented in a different way, can be displayed as a list, can be displayed as a picture, and sometimes only a subset of the data is displayed on demand.

Controller: The main purpose of adding a controller between model and view is "decoupling", which is to eliminate the coupling between model and view. When the user interacts with the view, the view notifies the controller that the data has changed in the view, and the controller will react to the change in the model. The controller plays the role of escaping data in this process (because the data presented in the view may be text or numbers that are easy for the user to read, and the data stored in the model may be more efficient but not easy to read directly binary or other storage methods such as relational databases, Controller can assume responsibility for transforming these two data forms).

The decoupling action of the controller is shown (note: The illustrations in this article derive from the book "Cocoa Design Pattern", Erik M.buck and Donald A.yacktman):

In the first step, the slide button changes to send a message to the controller; The second step, the controller sends the message tells the Model button location changes need to update the data value; The third step, the model Update data Notification controller; Fourth step, The controller completes updates to other view controls that need to be updated in the view, such as the text input box above.

In the whole process above you might think that model and view can interact directly, why introduce a controller? The reason is that view is often changed according to the user's needs (believing that a friend who often deals with customers is deeply impressed), and that the user data format is sometimes changed (for example, the customer requires data to be migrated from the MySQL database to Oracle). Separating the view from the model is extremely important.

MVC in the Cocoa

In the cocoa framework, it can be said that MVC design patterns are used to the extreme. Not only is the entire framework based on MVC design (see), but MVC is also widely used in a smaller scope.

Core data simplifies the design of many of the application's model parts; Applicationkit contains some classes that are common to view and controller. The Foundation provides access to operating system interfaces, NSObject base classes, scripting support, and other features.

Summary

The MVC design pattern reduces the coupling between modules in the program, but sometimes increases the complexity of the program. In the long run, a clear subsystem separation design such as MVC can reduce the maintenance cost of the system and make it easy to enhance and extend the function of the system. Another consideration is that the separation of subsystems has also brought great convenience to the software testing, for example, we can directly test the upgraded system model, not necessarily through the user interface to test, because when the user interface test fails, We do not know whether the interface is causing the model itself or whether it is caused by both. Then again, the view and model of a system is usually developed by different teams, so the clear separation of each subsystem is particularly important.

iOS design mode--mvc (Model-view-controller)