View the design of the MVC Architecture From the MVC Framework

Reprinted from: http://blog.csdn.net/bluishglc/article/details/6690693 View the design of the MVC Architecture From the MVC Framework

Although MVC is no longer a new topic, from the design of some excellent MVC frameworks in recent years, we will still find some new highlights of MVC Architecture Design. This article will explain some disadvantages of the traditional MVC Architecture, understand how some excellent MVC frameworks solve these problems, and reveal the design ideas and Design Concepts Reflected in them.

MVC Review

As a classic-to-non-classic architecture model, the success of MVC is inevitable. Different people may have different interpretations. The author agrees with the following idea: by separating components with similar responsibilities and properties, MVC divides the system into three parts: model, view, and controller. Each part is relatively independent and has a single responsibility, you can focus on your core logic in the implementation process. MVC is a reasonable sorting and splitting of system complexity. Its ideology is actually "separation of Focus ". As for the division of responsibilities and relationships between the three elements of MVC, I will not go into details here, but I will give a very detailed description.

Figure 1: Functions and relationships of MVC components [I]

View and controller decoupling: mediator + secondary event Delegation

When I developed a swing-based GUI application in my early years, I deeply realized the Close Coupling Between view and controller in the MVC Architecture Practice. In many event-driven GUI frameworks, such as swing, any operation on the view triggers an event and processes it in the listener response method. If you want the view to register as the listener of the event, you must add a reference to the Controller in the view. This is not what MVC wants to see, in this way, view and controller are closely coupled. If the Controller is registered as a listener, the event response will be borne by the Controller, which will cause the Controller to process the presentation logic that it should not involve. The reason for the difficulty in decoupling between the view and controller is: most user requests contain the presentation logic of certain components and the business logic of certain components. The two logics are combined in one request. during processing, it is difficult for view and controller to divide their work reasonably. The key to solving this problem is to establish a mechanism between view and controller that can effectively separate the presentation logic from the business logic. In this regard, the Design of puremvc [II] is very worthy of reference. It solves the issue of tight coupling between view and controller by introducing the mediator + secondary event delegation mechanism.

Mediator is a design model, which seems to have a common application scenario in the componentized graphical interface framework, an example of a graphic interface program is also used to explain mediator. Mediator is designed to interact with a group of objects through a media object, avoiding mutual reference between objects and generating complex dependencies. When mediator is used in graphic interface programs, it is often used as an interactive media for a group of closely related graphical components to complete coordination between components (for example, clicking a button will make other components unavailable ). In puremvc, mediator is widely used and its positioning has undergone subtle changes. It is no longer just a media between graphical components, but also a media between graphical components and commands, this makes it no longer optional, but a required facility in the architecture. In the traditional MVC Architecture, mediator is the medium between view and controller (of course, it is still the medium between view ), all user requests sent from the view are passed through the mediator and then passed to the Controller. Its appearance relieves the Close coupling problem between the view and the Controller to a certain extent.

After the view, mediator, and controller are defined and clearly divided, the remaining problem is how to connect them to complete a user request, in this regard, the event mechanism plays a crucial role. The event mechanism allows the current object to focus on the transactions within its scope of responsibility, without worrying about who handles and how to handle the transactions that exceed the limit. The current object only needs to broadcast one event, there will be other objects interested in this event to take over the next step. There is no direct dependency between the current object and the successor object, or even cannot perceive each other's existence, this is an important reason why event mechanisms are generally considered a loosely coupled mechanism. Let's talk about this topic.
In design), the famous domain event pattern is also created based on the characteristics of the event mechanism. It is designed to ensure the purity of the domain model, avoid the direct dependence of the domain model on Repository and service. Back to puremvc, let's look at how the event mechanism concatenates views, mediator, and controller in the Process of processing user requests. In puremvc, when a user requests a request, the graphic component first implements its own display logic in its own event response method, and then collects data, place the data in a new event and broadcast it out. This is the first event Delegate. This event will be monitored by a mediator. If you need assistance from other graphical components to process this request, mediator will coordinate the presentation logic they should handle, then mediator sends an event again (this event is called notification in puremvc). This event will prompt a command to execute and complete the calculation of the business logic. This is the second event Delegate. During the two event delegates, the first event Delegate allows the graphic components of the parties to "process the presentation logic within their respective scopes of responsibility" and then easily "exit ", this is free from being dragged down by "coordinating other graph processing residual presentation logic" and "selecting and assigning business objects to process business logic. While "coordinating other graphical components to process the residual display logic" is obviously the responsibility of the mediator, so the first broadcast event was assigned to the mediator.
After the coordination of graphic components is completed, the Mediator does not intervene in the work of "selecting and delegating business objects to process business logic". This is not its responsibility. Therefore, the second event Delegate happens. A new event is broadcast by the mediator and then responded by a command, the command completes the final work-"select and delegate the business object to process the business logic ".

Figure 2: mediator + secondary event Delegation

To sum up, puremvc introduces mediator between the view and controller, turning the view and controller into indirect dependencies, and delegates user requests from the view to the mediator, and then from the mediator to the Controller in the event mode, mediator + secondary event delegation is a powerful decoupling mechanism that completely decouples views from controllers.

Natural-granularity regression from controller to command

Currently, many mainstream MVC frameworks have introduced the command mode in design. The introduction of the command mode has changed the structure of the traditional MVC framework, and the biggest impact is the controller. In the traditional MVC Architecture in the past, a controller may have multiple methods. Each method usually corresponds to a user action. Therefore, a controller usually corresponds to multiple user actions, in the command-based MVC Architecture, a command usually corresponds to only one user action. In the traditional MVC Architecture, the process of assigning a user action to a method of a controller is changed to the one-to-one binding process of useraction and command in the command-based MVC Architecture. If the traditional controller is managed by the user
To establish a "centralized" Action ing between action and model, the command-based management method is to establish a "point-to-point" direct connection ing between user action and model.

Figure 3: evolution from controller-based to command-based architecture

There is a reason for the transition from mainstream MVC frameworks to command. In addition to the advantages of command itself, a very important reason is that the granularity of controller is difficult to grasp due to the lack of reasonable organizational basis. Different from view and model, the view and model have their own natural granularity organization basis. The view's organizational granularity directly inherits the user interface design, the organizational granularity of the model is based on a certain analytical design idea (such as OOA/d) for Domain Modeling. The controller needs to coordinate the view and model at the same time, however, the organizational structure and granularity of the view and model are not equal, which makes the controller face the question of "how many domain objects can be communicated and coordinated within the scope of the View, designers often feel at a loss when designing the Controller because they cannot find a reasonable organizational basis. In contrast, the command has no confusion about the controller, because the command has a natural organizational basis, which is the user
Action. It is natural and simple to design a command for a user action and map the two together. However, it should be noted that this does not mean that the granularity of all commands is the same, because different user actions represent different business volumes, therefore, it is also determined that the command is "big" and "small. Following the good design principles, it is recommended to break down some "large" commands and extract some reusable components from them and encapsulate them into some "small" commands. Many MVC frameworks define some related interfaces and abstract classes to support command Assembly based on the combination mode.

Whether it is based on the Controller or command, the responsibilities of the controller defined in the MVC Architecture for "Coordinating view and model interaction" will not change, and the corresponding components and mechanisms are required to carry and implement them. In the command-based architecture, command assumes part of the responsibility of the Controller in the past. In a sense, command is a fine-grained controller, but its features are passive. On the one hand, it has much weaker control over the view and model than the controller. For example, in general, the command will not directly manipulate the view. On the other hand, it does not know itself and what kind of user
The action is mapped together, and you do not know under which circumstances the execution will be triggered. To support command execution, additional registration, binding, and triggering mechanisms are required. These mechanisms, together with command, implement the Controller's responsibilities. Most of the command-based MVC frameworks now implement and encapsulate these important mechanisms. In a sense, these frameworks themselves assume the Controller role.

Summary

This article mainly analyzes the two major disadvantages of the traditional MVC Architecture in the past: Close Coupling Between view and controller and difficulty in controlling the Controller granularity, this article introduces how some MVC frameworks deal with these problems. The outstanding design ideas embodied in these design schemes are worth learning.

[I] picture Source: http://java.sun.com/blueprints/patterns/MVC-detailed.html

[II] puremvc is an MVC Framework that was initially implemented using ActionScript 3 and now has an implementation version on a multi-language platform. Site: http://puremvc.org/