iOS design mode three: MVC pattern

Referring to the MVC in iOS that had to mention the old man in the Fall 2011 Stanford Course, his iphone development Open class was the most accurate and straightforward to describe the MVC pattern in iOS.

Model-View-controller

This model should be called MCV, using the controller to separate the model and view, that is, the model and view do not know each other's existence, nothing involved, they are like a team of noisy colleagues, if there are projects need them to participate in, Then it is better to have a third party to manage the communication and coordination between the two of them. This third party is the controller .

Since the management, then put the controller to the project manager, so that they do what they have to do. As the old man in Stanford said, the view is the controller's henchman.

Let's take a look at this picture (from the Stanford Open Class courseware):

The line between the view and controller, model and controller is virtual, and the model and view are double yellow lines, and the driver's license knows what it means to cross the line.

Most of the connections between the controller and the view can be connected in Xcode by holding down CTRL. such as outlet, such as delegate. With these connections, the communication between them was unimpeded.

1) The user's operation on the view can tell the controller directly to the controller to respond

2) View required proxy can also be assigned to the controller to get the controller to complete

3) View needs the data source also needs the controller to provide

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

The controller also requires the participation of a role: model

As the name implies, the model. I think that using the domain of the MVC in ASP to describe the better understanding, the domain. For example, you want to develop a book management system, the model depicts the title of the book, the price, the author, who borrowed, the number borrowed, all about the application of the field of data.

We can give the model a simple definition: it describes an application of all the data structures that need to be abstracted, the relationships between them, and the paths they need to get the data (local, remote), etc.

With the model, when the controller wants to get the number, how to take all the line.

Looking closely at the diagram above, there is a controller to the model arrow, no model to the controller arrow. Because the model does not need to know the presence of the controller, this can reduce coupling and increase the likelihood of code reuse. Move the model you have defined to another project, and you can use it as well.

But the problem comes, when the model data has been updated, has been modified, how to notify the relevant controller? Note that there is an antenna above the model, high-end! Wireless is used because the model does not know who to send the changes to, but model can broadcast, model view: Who cares about my changes to whom to listen to, I am not interested in who listened to me.

There are two ways to broadcast: Notification and KVO (all design patterns, which are detailed later in this series)

Well, the relationship between them has a basic concept. The MVC pattern is like this, dividing the originally disorganized classes into three piles, strictly supervised, and acting according to the rules.

Or that sentence:

Ultimately, it's all about making the coupling between classes more loosely. Good code should be open for extensions and closed for modifications .

iOS design mode three: MVC pattern