IOS-MVC design mode, iosmvc

IOS-MVC design mode, iosmvc

MVC design pattern

Overview: Model-View-Controller (MVC), that is, Model-View-Controller. It divides the software system into three parts: Model, View, and Controller.

MVC Functions

M (model)

The core of an application, used to process the logic of Application Data

V (View)

Process the display of application data, usually created based on the Model

C (Controll)

Process User Interaction

Reads data from the view, controls user input, and sends data to the model

Communication between MVC

Illustration (courseware from the cs193 course of Stanford University)

This mode is actually called MCV. The model and view are separated by the Controller, that is, the model and view do not know each other's existence, they are like colleagues in a team who have a fight. If a project requires them to participate, it is best to have a third party to manage the communication and coordination between them. This third party isController.

Now, let's put this controller into the project manager, so that they have to do what they do. As the old guy Stanford said, the view is the Controller's dog leg. Let's take a look at this picture.

 

 

First, let's look at the lines between them by looking at the messy arrows. The lines between view and controller, model and controller are virtual, while the lines between model and view are double yellow lines, if you have taken a driver's license, you must know what it means to pass this line.

 

Most of the connections between the Controller and the view can be connected by pressing ctrl in Xcode. For example, outlet, for example, delegate. With these connections, communication between them is smooth.

1) The user's operations on the view can directly tell the Controller to let the Controller respond.

2) The view proxy can also be assigned to the Controller for the Controller to complete.

3) the data source required by the view must also be provided by the Controller.

In short, the controller is very busy because it is very passive.

The Controller also requires the participation of a role: model

Model. I think it is better to use the mvc domain in asp.net to describe the domain. For example, if you want to develop a library management system, the model depicts the book title, price, author, who borrowed it, and the number of times it borrowed it, all data about this application field.

We can give a simple definition to the model: it describes the relationship between all the data structures that an application needs to abstract and the data, there are also ways they need to obtain data (local and remote.

With the model, the controller can get the data whenever it wants.

 

Observe carefully the figure above. There is an arrow from the Controller to the model, and there is no arrow from the model to the Controller. Because the model does not need to know the existence of the controller, this can reduce coupling and improve the possibility of code reuse. You can also use the defined model to move it to another project.

But the problem arises. When the model data has been updated and modified, how can we notify the relevant controller? Note that there is an antenna above the model, high-end! The reason for using wireless connection is that the model does not know who to send the changes, but the model can be broadcast. The model's point is: Who cares about the changes and who can listen to them, I am not interested in who I listen.

There are two broadcast methods: Notification and KVO (both are design patterns. This series will be detailed later)

 

Well, the relationship between them is basically a concept. The mvc pattern is like this. It divides the originally disorganized classes into three heaps, which are strictly regulated and act according to rules.

Or that sentence:

In the end, everything is to make the coupling between classes more loose. Good code should beExtended and openClose Modification.

This graphic Section