IOS design pattern-MVC (Model-View-Controller)

Modol View Controller (MVC) is one of the earliest and most successful design patterns that can be reused. It was used successfully in a program written in smaltalk for the first time in 1970s. Based on the MVC design model, the overall architecture of cocoa can be divided into three subsystems: model, view, and controller. We can understand the data model, view, and controller accordingly.

Modol view and controller roles

To understand the role of each subsystem in the MVC design pattern, we need to understand the functions and behavior of an application. We know that an application usually needs to store data information, retrieve data information, present the data information to users, and allow users to edit the data (add, delete, query, modify, and perform other operations ). Then the MVC roles are:

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

View:Displays data in a certain form as a user and allows the user to operate on the data. The key to understanding the view is to understand that the same data can be displayed in different ways, in the form of a list, in the form of an image, and sometimes only part of the data needs to be displayed as needed.

Controller:The main purpose of adding a controller between the model and view is to "decoupling", that is, to eliminate coupling between the model and view. When a user interacts with a view, the view notifies the Controller that there is a change to the data in the view, and the Controller then reflects the change to the model. Controller plays the role of escaping data in this process (because the data displayed in the view may be text or numbers that are easy for users to read, the data stored in the model may be binary files that are relatively efficient but not easy to read directly, or other storage methods such as relational databases, the controller can assume the responsibilities of converting these two data forms ).

Shows the decoupling effect of controller (Note: The illustrations used in this article are from cocoa design pattern, Erik M. Buck and Donald A. yacktman ):

Step 1: send a message to the controller when the sliding button changes. Step 2: the controller sends a message to notify the model button that the data value needs to be updated when the position of the button changes. Step 3, the model notifies the Controller after updating the data. Step 4, the Controller updates other view controls to be updated in the view, such as the text input box above.

During the above process, you may think that model and view can directly interact with each other. Why should you introduce controller? The reason is that views are often changed based on user needs (I believe friends who often deal with customers are deeply touched by this ), in addition, the user data format may change sometimes (for example, the customer requires that the data be migrated from the MySQL database to the Oracle database). In this way, it is extremely important to separate the view and model.

MVC in cocoa

In the cocoa framework, it can be said that the MVC design pattern has been used to the extreme. Not only is the entire framework designed based on MVC (SEE), but MVC is also widely used in a smaller scope.

Core Data simplifies the design of model parts of many applications. applicationkit includes view and controller generic classes. Foundation provides access to operating system interfaces, nsobject base classes, script 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 system maintenance overhead and facilitate system function enhancement and expansion. Another consideration is that the separation of subsystems also facilitates Software Testing. For example, we can directly test the upgraded system model, it is not necessary to test through the user interface, because when the test fails through the user interface, we do not know whether the interface is caused by the model itself or both. In addition, the view and model of a system are usually developed by different teams, so that the clear separation of each subsystem is particularly important.