Understanding of the MVC design pattern for iOS learning

Model - View - controller (MVC) paradigm in cocoa programming.

1. What is MVC?
2. What is the mode of communication between M, V and C?

Understanding the concept of MVC is critical to the development of cocoa programs.

First, the concept of MVC

MVC is Model-view-controller, the model - View - controller , what are these things?

MVC divides a software system into three parts: Model,view,controller. In cocoa, every object in your program will obviously belong to only one of these three parts, but not the other two at all.

Model = What is your program (Not how your program is displayed)

Let us give an example, when we were in high school, our step-by-step electronic dictionary has a game called "Thunder Fighter", that is, "jerk off" game, model is: How much damage is your small aircraft? What weapons, shells, missiles, or laser cannons are on your little plane? How much blood do you have on your little plane? Wait a minute. To summarize, it is the function that your program will implement, or the things it can do.

Controller = How to make your model present to the user (Program logic)

Controller is the logic inside the program, in most cases you will not see it, it will be the model and view bundled together, it will handle the user input, for example, you press the Cannon key, the controller will be the internal logic to handle your request, and on the screen to make corresponding display, You will see a small plane on the screen emitting shells hitting the enemy aircraft. This is also an example of the controller controlling the display of the view. So you can think of the controller as a bridge connecting M and V.

View = What you see on the screen (is the "Minion" of your controller)

Then the front of the small plane, view is: what your small plane is like, one or two wings, a few guns, and your plane on the screen location and so on. In short, the components you see on the screen can be categorized as view.

MVC can help ensure maximum reusability of the program to help implement. Each MVC element works independently of each other, and by separating these elements, it is possible to build a maintainable, independently updated program.

AC mode between two, M V C

OK, now let's talk about how the elements in MVC are communicated.

We divide the program into three parts, but we do not want them to be completely independent, because in that case our program will be meaningless and functional. There must be some kind of connection between them, so that they can organically become a whole to achieve a variety of powerful functions. And this connection is the way we talked about communication. Let's take a look at the diagram below, which is from the Stanford University CS193 Course courseware.

There are several lines dividing the three parts, with yellow lines, dashed lines, and solid white lines. We think of them as signposts. As you can see, there are two yellow lines between M and V, what does that mean? It means you can't cross the Yellow Line, not in either direction. In the upper part of the graph, you can see the white dashed line, which means that you are free to cross it as long as it is safe. The white real floss? It means you can go through it, but you have to buy tickets or cross the tolls.

Well, if you feel that the analogy above doesn't make you understand, let's talk about something real.

First, let's look at the green arrows between C and M, where the direction of the arrow represents the direction of the "initiating the dialogue", that is, the C that initiates the conversation, and the answer is M. C can ask m various questions, but m just answer C's question or request, it can not take the initiative to ask C what. Remember the dotted line is unimpeded, so, C know all the things m, if the code to illustrate the matter, that is, C can import m header file or M interface (API). Because C can be through the API of M, so it can be unscrupulous to M request this request that.

Let's look at another Green arrow, which is between C and V, and the meaning of the previous Green Arrow, which means that C can communicate directly to V. You can think of the C to put V on the screen and set the properties of V, tell them when to disappear from the screen, divide them into groups, and so on. If C is not free to dictate to V, the display of the program will be very difficult, so C can speak to V without restriction.

As you may have noticed, this arrow also has a outlet (output port), outlet can be seen as a pointer from C to V, which is defined in C. Outlet gives us a lot of convenience, and it makes it easy and accurate to apply the order to V within C. C can have a lot of outlet, can have more than one, which also makes it more efficient to communicate with V.

Is it possible to communicate between M and V? Do you remember what the Yellow line means? It is totally not possible, so we are not allowed to communicate with M and V. This is because we do not want to have too much communication between the three parts, you think, if v in the display of the problem, such as a graph is not shown, we will go to find the error, because C can communicate with V, M can also communicate with V, we are going to check two parts. On the contrary, only C can communicate with V, in case of error, we just need to go to C where to find the reason, so it is not easy to find the error? Therefore, we do not allow a direct link between M and V, which is why there are two yellow lines between them.

A good application has the ability to interact with the user. Without good interactivity, the functionality of the program will be greatly limited. In MVC, V is in direct contact with the user, the user can not see M and C, so the interaction between the program and the user must be implemented through V, but V is only a view, it does not fully handle the user's requirements, so this requires that V must have some means to send information to C, transfer the user's interaction requirements. This means that the front white solid line represents the toll, you know that V can not know everything about C, but it can be a kind of "means" to communicate with C, the transfer of user interaction responsibility.

Let's talk about how v sends information to C. V There are three different ways to communicate with C.

The first is what we call the target operation (target-action). It works like this, C will "hang" a target in its own interior, the red and white target, and it will also distribute an action (the yellow arrow in the action) to the view object that will communicate with it (possibly a button on the screen), when the button is on time, The action is sent to the corresponding target so that V can communicate with C. But in this case, V just knows to send the action to the corresponding target, it does not know the class in C, and does not know what it is sending. Target-action is a method that we often use.

The second way we call it a delegate (delegate). Sometimes, V needs to be synchronized with C, and you know that user interaction is more than just pressing a button, a slider, and many other forms. OK, let's take a look at the delegate yellow arrow in the picture, and you'll find four small arrows on the arrow: Should,did,will, and one that's not labeled. The vast majority of delegate information is should,will,did in these three forms. In contrast to the English meaning, should represents a view object that will ask an object in C "Should I do that?" ", for example, there is a Web view, someone clicked on a link, and the Web view is going to ask" should I open this link? " Is it safe to do this? ”。 This is should information. What about Will and did? Will is "I'm going to do it", did it "I've done it". c sets itself to V's delegate (delegate), which lets v know: If v wants to know more about how the information will be displayed, send the delegate message to C. By accepting the delegate information sent by V, c will coordinate and deal with it accordingly. There is also a point where each v can have only one delegate.

The third way is the data source (datasource), and you know that V can't have the data it's going to display, so it's important to remember that. V wants others to help it manage the data that will be displayed, and when it needs data, it asks someone for help and gives it the data it needs. Moreover, the iphone's screen is small, and it can't display a view with a lot of information. Looking at the DataSource arrows in the picture, like delegate, V sends Cout,data at information to C to request data.

Well, this is the three form that v sends messages to C.

One last question. You see the white line between M and C, which means that m can not communicate directly, without limiting C. But sometimes, this direction of communication is necessary. When something in M changes, C needs to know about these changes, so how can we let C know about m changes? Notifications (Notification) and KVO are good ways to solve problems. That's how they work, and when something in M changes, they send a notice to C, "Hey, man, watch out, I've changed," or they'll send a pointer to change to C, or something. In short, their mode of work is like this.

Summarize:

C to M:api
C to V:outlet
V to C:target-action, Delegate,datasource
M to C:notification,kvo

Original source: http://blog.sina.com.cn/s/blog_4a3dcc3901010062.html

Understanding of the MVC design pattern for iOS learning