How to understand MVC design patterns

MVC (Model View Controller)

M-Models (model)

V-Views (view)

C-Controllers (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.

MVC it makes it mandatory to separate the input, processing, and output of the application. Using an MVC application is divided into three core parts: model, view, controller. Each of them handles their own tasks. Layering concepts

(i) Model objects
Model objects encapsulate the application's data and define the logic and operations that manipulate and manipulate the data. For example, a model object might represent a role in a game or a contact in an address book. The actions that the user creates or modifies data in the view layer are communicated through the Controller object and eventually the model object is created or updated. When a model object changes (for example, new data is received over a network connection), it notifies the controller object that the Controller object updates the corresponding View object. Of the three parts of MVC, the model has the most processing tasks. For example, it may use artifact objects such as EJBS and ColdFusion 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.

(ii) View object
A View object is an object that the user can see in the application. The View object knows how to draw itself and may respond to the user's actions. The primary purpose of a View object is to display data from an application model object and make that data editable. However, in an MVC application, the View object is usually detached from the model object. In iOS application development, all controls, windows, and so on are inherited from UIView, corresponding to the V in MVC. UIView and its subclasses are responsible for the implementation of the UI, and the events generated by UIView can be entrusted to Uiviewcontroller.

(iii) Controller object
A Controller object acts as a medium between one or more view objects and one or more model objects in an application. The Controller object is therefore a synchronous pipe program through which the view object understands changes to the model object, and vice versa. The Controller object can also perform settings and reconcile tasks for the application and manage the life cycle of other objects.

The Controller object interprets user actions in the View object and communicates new or changed data to the model object. When a model object changes, a controller object communicates the new model data to the View object so that the view object can display it.

Why use MVC
   First, the most important thing is that multiple views can share a model, and now there are 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.
because 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 Adobe Flash 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. Advantages of
MVC
(i), low-coupling
View layers and business tiers are decoupled, allowing you to change the view layer code without recompiling the model and controller code, again Changes to an application's business process or business rules can only be changed by 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.

(ii), 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.

(iii), lower life cycle costs
MVC reduces the technical content of developing and maintaining user interfaces.

(iv), maintainability
Separating the view layer and the business logic layer also makes the application easier to maintain and modify.

(v), in favor of 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.

The summary is the following three points:

(1), model and view can never communicate with each other, can only be passed through the controller.

(2), controller can directly with the model dialogue (read and write call model), model through the notification and KVO mechanism and the controller to communicate indirectly.

(3), controller can directly with the view dialog, through outlet, direct operation View,outlet directly to the control in the view, view through action to the controller to report the occurrence of the event (such as the user Touch me). The controller is the direct data source of the view (the data is most likely the controller has been obtained from the model and processed). The controller is the proxy for the view (delegate) to synchronize the view with the controller.

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

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 be communicating with it (possibly a button on the screen), when the button is on time, the action will be 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. 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),

V cannot have the data it wants to display, it is important to remember this. 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.

For different uiview, there are corresponding uiviewcontroller, corresponding to the C in MVC. For example, the UITableView used on iOS, the controller that corresponds to it is uitableviewcontroller.

How to understand MVC design patterns