Detailed MVC Design Patterns

1 MVC Introduction

It is well known that MVC is not a design pattern, is a larger pattern than the design pattern, called the design pattern is unreasonable, it should be said that MVC is a software development architecture pattern, it contains a lot of design patterns, the most closely is the following three kinds: OBSERVER (Observer mode), Composite (combined mode) and strategy (policy mode). So the MVC pattern is also called the compound pattern. The basic idea of the MVC (Model-view-controller) pattern is the separation of data, display, and processing. The model is responsible for data management, the view is responsible for the data display, and the controller is responsible for the business logic and response strategy.

From the perspective of MVC formation, there are only two elements of the model and view initially. The model encapsulates the data and provides an operational interface, which is used to represent data and to receive user requests. The model is independent, and the view relies on the model: fetching data from the model for display, sending user requests to the model, and refreshing itself based on the returned results.

When multiple views are required to represent the same model, the situation changes: After a view modifies the data, it is not only refreshing itself, but all other views are refreshed. If the view notifies other views, it needs to know all the other views, because each view is likely to make changes, and each view has to know all the other views, which are too complex to maintain, and not easy to add new views. If you let the model notify all view updates, the model's independence may be affected. Using the Observer (OBSERVER) mode can solve the above contradiction, thus realizing: the model notifies the view, and the model does not depend on the concrete view, the concrete view is independent of each other.

A view is the recipient of a user request, but not a handler for the request. Because the interface is variable, if the business code and Interface code are put together, frequent interface modifications can break the more stable business code. Separating the business logic from the one controller is responsible for avoiding this interference.

The model notifies all views directly when the state changes, and the view queries the model for state data and then refreshes itself. When the user issues an action, the view sends the message to the controller, which is processed by the business logic and the controller invokes the model when the data needs to be queried or updated.
The MVC architecture separates data processing, program input and output control, and data display, and describes the communication between objects of different parts. Makes software maintainability, extensibility, flexibility and encapsulation greatly improved; MVC (Model-view-controller) decomposes the composition of the system into three parts of M (model), V (view), C (Controller). The view represents the display of data on the screen. The controller provides process control, which acts as a connection between the model and the view. The controller itself does not output any information and does any processing, it is only responsible for the user's request to the model of the operation, and call the corresponding view to display the model processed data.

The same data can be displayed differently and processed in a variety of ways. The display is just the performance data, and processing is the process of changing the data according to the user request, not only the business logic but also the response strategy. The response policy is the responsibility of the Controller, and the view can use different controllers to provide different responses, which is the application of the policy (strategy) mode.

In addition, MVC allows views to be nested, using the combined (Composite) pattern to consistently work with combined views and normal views.

The three main features of MVC are the representation of a model in multiple views, changing the response policy in the same view, and allowing the view to be nested. In the internal structure, the main relationship of MVC is given by the observer pattern, the strategy pattern and the combination pattern. The model view relationships determined by the observer pattern are among the most important.

There are many variants of the MVC pattern. In the preceding structure, a refresh of the model notification view, known as active MVC, is called the passive MVC structure if the model is updated later by the controller to notify the view. In many applications, there is no obvious controller role and no view nesting. It can be seen that the three patterns that make up MVC are subject to change, depending on the actual needs. A Web browser is an example of a passive MVC structure.
"A browser is an interactive program that, conceptually, consists of a group of customers, a set of interpreters, and a controller that manages them." The Controller forms the central part of the browser, which interprets mouse clicks and keyboard input, and calls other components to perform user-specified actions. For example, when a user types a URL or clicks on a hypertext reference, the controller calls a customer to retrieve the document from the remote server on which the desired document is located, and invokes the interpreter to display the document to the user. Each browser must contain an HTML interpreter to display the document, and the other interpreter is optional. The input of the HTML interpreter consists of a document that conforms to the HTML syntax, and the output is made up of a format version document located on the user's display. The interpreter handles layout details by translating HTML rules into commands that are appropriate for the user's display hardware. One of the most important functions of the HTML interpreter is to include options. The interpreter must store information about the relationship between the locations on the monitor and the items that are targeted in the HTML document. When the user selects an item with the mouse, the browser determines which item is selected by the user by the current cursor position and stored location information. "

2. Why use the MVC architecture in Web applications

Changes in user interface logic are often more frequent than business logic, especially in Web-based applications. For example, you might add a new user interface page, or you might completely disrupt an existing page layout. Do not affect the data and business logic as much as possible for the changes that are displayed.

Most Web applications now mix data codes with representations. The more experienced developers separate the data from the presentation layer, but this is often not easy to do and requires careful planning and ongoing attempts. MVC is fundamentally mandatory to separate them. Although it takes some extra work to construct an MVC application, the benefits are no doubt

2.1 Increase code reuse rate

The most important point is that multiple views can share a model, whether the user wants a flash interface or a WAP interface, and can handle them with a single model. Because data and business rules are separated from the presentation tier, you can maximize the reuse of code.

2.2 Improve the maintainability of the program

[3] Because the model is self-contained and detached from the controller and view, it is easy to change the data layer and business rules. For example, porting a database from MySQL to Oracle, or changing an RDBMS-based data source to LDAP, simply changes the model. Once the model is implemented correctly, the view will display them correctly, regardless of where the data comes from. The application of MVC architecture makes the three parts of the program oppose each other, which greatly improves the maintainability of the program.

2.3 facilitates team development

In the development process, can better division of labor, better collaboration. Helps develop high-quality software. A good project architecture design will reduce coding effort: the MVC Architecture + code generator is the ideal choice for most Web applications. Part of the model, and stored procedures are generally available tools are automatically generated. Control (Controller) is relatively stable, generally due to architects (and possibly experienced people) to complete, then the entire project needs to manually write code where there is only the view. In this mode, personal ability is not particularly important, as long as the people who understand the basis of grammar can be written, regardless of the project members to write what kind of code, is within the control of the project manager. Even if there is a substitution in the middle of the project, it won't be too much. In the development of a team with uneven individual ability, it is very ideal to use MVC development.

3 Advantages and disadvantages of the MVC architecture Advantages of 3.1 MVC

The benefits of MVC are reflected in the following areas:

(1) Facilitate the team to develop division of labor and Cooperation and quality control, reduce development costs.

(2) Multiple views can be established and used at run time for a model. The change-propagation mechanism ensures that all related views are in time to get model data changes, so that all associated views and controllers behave in a synchronous manner.

(3) The view and controller pluggable, allowing the exchange of views and controller objects, and can be dynamically opened or closed according to demand, and even during the operation of object substitution.

(4) Portability of the model. Because the model is independent of the view, it is possible to migrate a model independently to the new platform work. All you need to do is make new changes to the view and controller on the new platform.

(5) A potential frame structure. The application framework can be built on this model, not just in the design of the interface.

Disadvantages of 3.2 mvc

The shortcomings of MVC are reflected in the following areas:

(1) Increase the complexity of the system structure and implementation. For a simple interface, strict adherence to MVC, which separates the model, view, and controller, increases the complexity of the structure and may result in excessive update operations and reduced operational efficiency.

(2) The view is inefficient in accessing model data. The view may need to call model multiple times to get enough display data.

(3) 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. At the same time, due to the strict separation of the model and view, it is also difficult to debug the application.

3.3 MVC patterns can be decomposed into the following design patterns

In the introduction of the Gof book, there is a section "Design Patterns in Smalltalk MVC" that describes the patterns used in the MVC pattern. It probably conveys this message to us that the compositing mode + Strategy Mode + Observer pattern is approximately equal to the MVC pattern (and of course the MVC pattern is more). That is, it is in most cases the following patterns:

(1), observer mode

(2), synthetic mode

(3), policy mode

4 Talk Talk about Three roles in the MVC architecture pattern

• Model (model side)

MoD encapsulates the data source and all the operations based on that data. In a component, the model often represents the state of the component and the method of manipulating those states, often a series of public methods. With these public methods, all the functionality of the model side can be obtained.

In these public methods, some are the method of value, so that other parts of the system can get the internal state parameters of the model side, and other methods allow external modification of the internal state of the model side. The model side must also have methods to enlist the view so that the view side can be notified when the internal state of the model side changes. We can define a subject interface ourselves to provide the interfaces required to enlist and notify the view, or to inherit the Java.util.Observable class so that the parent class does this.

• multiple View ( views side )

The view encapsulates a display of the data source model. A model can be made up of multiple views, and you can dynamically enlist the views you want when you need them. And a view can theoretically be associated with different models.

As mentioned in the preface, the MVC pattern is used in compositing mode, because the view can be nested in the view side, for example in a JFrame component, can have a menu component, a lot of button components and so on.

• multiple Controller ( director side )

Encapsulation is the operation of the outside acting on the model. Typically, these actions are forwarded to the model and the corresponding one or more methods in the model are called (this method is the method of changing the value that was described earlier in the introduction of the model). The general controller acts as a communication between the model and the view, processes the user's input on the view, and forwards the model to change its status value. So the model and the view can be loosely coupled, and even can not know each other, and the controller connected to the two parts. It is also mentioned in the preface that MVC uses a strategy pattern because the view implements a specific response strategy using an instance of a particular controller, replacing different controllers, which can change the view's response to user input.

MVC (Model-view-controller): Models utilize "observer" to allow controllers and views to be updated with the latest state changes. On the other hand, the view and controller implement the "policy mode". The controller is the behavior of the view; The view is used to manage the display components using the "composite Mode" style.

The following MVC explanatory diagram is a good indicator of this pattern:

• The model uses the observer pattern for the observer to update, while maintaining decoupling between the two.
• The controller is the view's policy, and the view can be implemented using different controllers, resulting in different behaviors.
• The view uses a combined pattern to implement the user interface, and the user interface typically combines nested components like panels, frames, and buttons.
• These models work together to decouple the three layers of the MVC pattern, which keeps the design clean and resilient.

Detailed MVC Design Patterns