Understanding of MVC design pattern and iosmvc Design Pattern for iOS Learning

Understanding of MVC design pattern and iosmvc Design Pattern for iOS Learning

In cocoa ProgrammingModel-View-Controller(MVC) pattern.

 

Understanding the concept of MVC is crucial to cocoa program development.

 

I. MVC Concept

MVC is Model-VIew-Controller, that isModel-View-ControllerWhat are these things?

 

MVC divides the software system into three parts: Model, View, and Controller. In cocoa, every object in your program will obviously belong to only one of these three parts, but not the other two.

 

Model = What is your program(Instead of how your program is displayed)

 

Let's take an example. When we went to middle school, we had a game called "Thunder fighter" in our BBG electronic dictionary, that is, the "airplane hitting" game. The Model was: what is the attack power of your small plane? What weapons, shells, missiles, and laser guns are mounted on your plane? How much blood does your plane have? And so on. To sum up, it is the function that your program will implement or what it can do.

 

Controller = how to present your model to users(Program Logic)

 

Controller is the internal logic of the program. In most cases, you will not be able to see it. It binds the Model and View together, and it will process user input. For example, if you press the key to open the gun, the Controller will use internal logic to handle your requirements and display them on the screen. You will see a small plane on the screen hitting the enemy. This is also an example of Controller control View display. Therefore, you can regard Controller as a bridge connecting M and V.

 

 

View = what you see on the screen(It is your Controller's "slave ")

 

Then the View of the plane is: What does your plane look like, whether it has two wings, how many gunshots, or where your plane is on the screen. In short, all the components you see on the screen can be classified as views.

MVC can help ensure maximum reusability of the program. Each MVC element operates independently of each other. By separating these elements, you can build a maintenance and update program.

 

2. Communication Mode between M V C

 

Now let's discuss the communication methods between various elements in MVC.

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 relationship between them, so that they can be organically integrated to implement various powerful functions. This kind of contact is the communication method we mentioned. Let's take a look at the figure below, which is from the courseware of the CS193 course of Stanford University.

 

 

In the figure, there are several lines that divide the three parts into yellow lines, dotted lines, and white solid lines. We think of them as road signs. You can see that there are two yellow lines between M and V. What does this mean? It means that you cannot cross this yellow line, and you cannot cross any direction. On the top of the graph, you can see the white dotted line, which means you can freely traverse it, as long as it is safe. What about the white solid line? It means you can pass through, but you must buy a ticket or pay a toll.

 

Well, if you don't think the previous metaphor makes you understand it, let's talk about something real.

 

First, let's look at the Green Arrow between C and M. The direction of the arrow represents the direction of "initiating a dialogue", that is, C is initiating a dialogue, M is the answer. C can ask M various questions, but M only answers C's questions or requirements, and it cannot actively ask C for anything. Remember that the dotted line is unobstructed, So C knows everything about M. If code is used to explain it, that is, C can import M header files or M interfaces (APIS ). Because C can use M's API, it can demand this requirement from M without authorization.

 

Let's take a look at another Green Arrow, which is between C and V. It has the same meaning as the previous Green Arrow. It means C can communicate directly with V. You can think about it. C wants to put V on the screen, set the V attribute, tell them when to disappear from the screen, and divide them into groups. If C cannot send a command to V freely, the display of the program will be very difficult. Therefore, C can speak to V without restrictions.

 

You may have noticed that there is an outlet (output port) on this arrow. outlet can be seen as a pointer from C to V, which is defined in C. Outlet provides us with great convenience, which enables us to easily and accurately execute orders to V within C. C can have more than one outlet, which makes it more efficient to communicate with V.

 

Can M and V communicate with each other? Do you still remember what the yellow line means? It is completely unavailable, so we do not allow M and V to communicate. This is because we don't want to have too much communication between these three parts. You can think about it. If V has a problem during display, for example, if a graph is not displayed, we have to look for an error, because C can communicate with V, and M can communicate with V, we need to check the two parts. On the contrary, if only C can communicate with V, when an error occurs, we only need to go to C to find the cause. Isn't it easy to find the error? Therefore, we do not allow direct connections between M and V, which is also the reason that there are two yellow lines between them.

 

Good applications must be able to interact with users. Without good interaction, the functions of the program will be greatly restricted. In MVC, V is in direct contact with the user, and the user cannot see M and C. Therefore, the interaction between the program and the user must be implemented through V, but V is only a view, it cannot completely handle user requirements. Therefore, it requires that V must have some means to send information to C and hand over the user interaction requirements. This means is the traffic fee represented by the previous white line. You know that V cannot know everything about C, but it can communicate with C through some "means" and hand over the responsibility for user interaction.

 

Next we will discuss how V sends messages to C. V has three different ways to communicate with C.

 

The first type is called target-action ). It works in this way. C will "hover" a target in its internal structure, which is a red and white target. Corresponding, it will also distribute an action (action, to the view object (possibly a button on the screen) that will communicate with it. When the button is updated, the action will be sent to the corresponding target, in this way, V can communicate with C. However, in this case, V only knows whether to send an action to the corresponding target. It does not know the class in C or what it actually sends. Target-action is a common method.

 

The second method is called a delegate ). Sometimes, V needs to be synchronized with C. You know, user interaction is not just about pressing a button, sliding a slider, but also in many forms. Let's take a look at the delegate yellow arrow in the figure. You can find four small arrows on the Arrow: shocould, did, And will. There is another one that is not marked. The vast majority of the delegate information is in the form of shocould, will, and did. Corresponding to the English meaning, shocould indicates that the view object will ask a certain object in C, "should I do this ?", For example, if someone clicks a link in a web View, the web View will ask "should I open this link? Is this safe ?". This is the account information. What about will and did? Will is "I am going to do this", did is "I have already done this ". C sets itself as the V delegate, which lets V know that if V wants to know more about how it will be displayed, it will send the delegate information to C. C will coordinate and process the delegate information sent by V. Another point is that each V can have only one delegate.

 

The third method is the data source. You know that V cannot have the data it wants to display. Remember this is very important. V wants others to help it manage the data to be displayed. When it needs the data, it will ask others for help and give it the required data. Furthermore, the iphone screen is small and cannot display views that contain a large amount of information. The datasource arrow in the figure is similar to delegate. V sends cout and data at information to C to request data.

 

Okay, this is three forms of information that V sends to C.

 

The last question. You can see the white line between M and C, which means M cannot communicate with C directly without restrictions. However, sometimes communication in this direction is necessary. When something in M changes, C needs to understand these changes. How can we let C know M changes? Notification and KVO are good solutions to the problem. They work like this. When something in M changes, they will send a notification to C, "Hey, dude, attention, I have changed ", or they will send a pointer pointing to a change to C, or something else. In short, they work like this.

 

Summary:

C-to-M: API
C-V: Outlet
V for C: Target-action, Delegate, Datasource
M for C: Notification, KVO

Source: http://blog.sina.com.cn/s/blog_4a3dcc3901010062.html