Turn---MVC design patterns

MVC (Model View Controller) model-View-controller:
MVC exists in the desktop program, m refers to the data model, v refers to the user interface, C is the controller. Using MVC is to separate the implementation code for M and V, so that the same program can use a different representation. For example, a batch of statistical data can be represented by a histogram, pie chart, respectively. C exists to ensure the synchronization of M and V, once m changes, V should be updated synchronously, from the example can be seen MVC is a special case of observer design pattern.
How MVC Works
MVC is a design pattern that makes it mandatory to separate the input, processing, and output of an application . Using an MVC application is divided into three core parts: model, view, controller. Each of them handles their own tasks. Layering concepts
View:

A view is an interface that the user sees and interacts with. For older Web applications, views are an interface of HTML elements, and in modern Web applications, HTML still plays an important role in the view, but new technologies are emerging, including MacromediaFlash and elephant xhtml,xml/xsl , WML, and some other identity languages and Web services.
How to handle an application's interface becomes increasingly challenging. One big benefit of MVC is that it can handle many different views of your application. There is really no real processing happening in the view, whether the data is stored online or an employee list, as a view, it is simply a way to output data and allow the user to manipulate it.
Model:
Models represent enterprise data and business rules. Of the three parts of MVC, the model has the most processing tasks. For example, it may use artifact objects such as EJBS and coldfusioncomponents to process the database. The data returned by the model is neutral, meaning that the model is independent of the data format, so that a model can provide data for multiple views. Because the code applied to the model can be reused by multiple views only once, it reduces the repetition of the code.
Controller
The controller accepts the user's input and invokes the model and view to complete the user's needs. So when you click a hyperlink in a Web page and send an HTML form, the controller itself does not output anything and do any processing. It simply receives the request and decides which model component is called to process the request, and then determines which view to use to display the returned data.
Why use MVC
First, the most important point is that multiple views can share a model, and now more and more ways to access your application. One solution to this is to use MVC, whether your users want a flash interface or a WAP interface, and use a model to handle them. Since you have separated the data and business rules from the presentation layer, you can maximize the reuse of your code.
Since the data returned by the model is not formatted, the same artifacts can be used by different interfaces. For example, many of the data may be represented in HTML, but they may also be represented by Adobeflash and WAP. The model also has the capability of state management and data persistence processing, for example, session-based shopping carts and e-commerce processes can also be reused by flash sites or wireless networking applications.
Because the model is self-contained and detached from the controller and view, it is easy to change the data layer and business rules of your application. If you want to port your database from MySQL to Oracle, or change your RDBMS-based data source to LDAP, just change your model. Once you've implemented the model correctly, the view will display them correctly, regardless of whether your data comes from a database or an LDAP server. Since the three parts of an application using MVC are independent, changing one does not affect the other two, so you can construct good loosely coupled components based on this design idea.
For me, the controller also provides the benefit of using a controller to join different models and views to complete the user's needs, so that the controller can provide a powerful means of constructing the application. Given some reusable models and views, the controller can select the model to process based on the user's needs, and then select the view to display the processing results to the user.
The advantages of MVC
1. Low coupling
The view layer is decoupled from the business layer, allowing changes to the view layer code without recompiling the model and controller code, as well as changes in an application's business process or business rules only need to change the MVC model layer. Because the model is decoupled from the controller and view, it is easy to change the data layer and business rules of the application.
2. High reusability and applicability
As technology continues to evolve, more and more ways to access applications are now needed. The MVC pattern allows you to access the same server-side code using a variety of different styles of view. It includes any web (HTTP) browser or wireless browser (WAP), for example, a user can order a product via a computer or via a mobile phone, although the order is different, but the way to order the product is the same. Since the data returned by the model is not formatted, the same artifacts can be used by different interfaces. For example, many of the data may be represented in HTML, but it is also possible to use WAP to represent the commands required to change the implementation of the view layer without any changes to the control layer and the model layer.
3. Lower life cycle costs
MVC reduces the technical content of developing and maintaining user interfaces.
4. Rapid Deployment
Using the MVC pattern allows for a considerable reduction in development time, which allows programmers (Java developers) to focus on business logic, and interface programmers (HTML and JSP developers) focus on presentation.
5. maintainability
Separating the view layer and the business Logic layer also makes Web applications easier to maintain and modify.
6. Beneficial to software engineering management
Because different layers have their own roles, each layer of different applications has some of the same characteristics, which facilitates engineering and tool-based management of program code.
The drawbacks of MVC
The drawback of MVC is that it doesn't have a clear definition, so it's not easy to fully understand MVC. Using MVC requires careful planning, and because its internal principles are complex, it takes some time to think.
You will have to spend a considerable amount of time thinking about how to apply MVC to your application, as well as the strict separation of the model and view, which also poses some difficulties for debugging the application. Each component needs to be thoroughly tested before it can be used. Once your artifacts have been tested, you can reuse them with no scruples.
Based on the developer's experience, because developers divide an application into three parts, using MVC also means that you are going to manage more files than ever before, which is obvious. It seems like our workload has increased, but remember that this is nothing compared to the benefits it can bring us.
MVC is not a good fit for small or medium-sized applications, and spending a lot of time applying MVC to applications that are not large in size will often outweigh the costs.
The MVC design pattern is a good way to create software, and some of the principles it advocates, such as content and display, may be better understood. But if you want to isolate the artifacts of models, views, and controllers, you may need to rethink your application, especially the architectural aspects of your application. If you accept MVC and have the ability to cope with the extra work and complexity it brings, MVC will give your software a new level of robustness, code reuse, and structure.

IOS MVC Design:

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 that you can't cross the Yellow Line, not in either direction, where M and V are completely separated. 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.

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.

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.

Here's a summary of what we've learned, cocoa is faithful to MVC, so understanding Cocoa's MVC is our key start, and hopefully this will make you understand something.

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

Turn---MVC design patterns