What is the MVC pattern_PHP tutorial-PHP Tutorial-php.cn

MVC pattern

MVC mode is the abbreviation of "Model-View-Controller", and the Chinese translation is "Mode-View-Controller". MVCApplicationProgram always consists of these three parts. Event (event) causes the Controller to change the Model or View, or both at the same time. As long as the Controller changes the data or properties of the Models, all dependent Views will be automatically updated. class is similar. As long as the Controller changes the View, the View will get data from the underlying Model to refresh itself. The MVC pattern was first proposed by the Smalltalk language research group and is used in user interaction applications. There are many similarities between the smalltalk language and the java language. They are both object-oriented languages . Naturally, SUN recommended the MVC pattern as a way to develop web applications in the petstore (pet store) case application. The architecture pattern. The MVC pattern is an architectural pattern that actually requires the collaboration of other patterns. In the J2EE mode directory, service to worker mode is usually implemented, and service to worker mode can be composed of centralized controller mode, dispatcher mode and Page Helper mode. However, Struts only implements the View and Controller parts of MVC. The Model part needs to be implemented by developers themselves. Struts provides the abstract class Action so that developers can apply Model to Struts. Frame. The MVC pattern is a complex architectural pattern, and its implementation is also very complicated. However, we have ended up with many reliable design patterns . The combination of multiple design patterns makes the implementation of the MVC pattern relatively simple and easy. Views can be regarded as a tree, which can obviously be implemented using Composite Pattern. The relationship between Views and Models can be reflected by the Observer Pattern. Controller controls the display of Views, which can be implemented using Strategy Pattern. Model is usually a mediator and can be implemented using Mediator Pattern.
Now let us understand where the three parts of MVC are in the J2EE architecture, which will help us understand the implementation of the MVC pattern. The corresponding relationship between MVC and J2EE architecture is: View is in Web Tier or Client Tier, usually JSP/Servlet, which is the page display part. The Controller is also in the Web Tier and is usually implemented with Servlet, that is, the logical part of the page display is implemented. Model is in the Middle Tier and is usually implemented using JavaBean or EJB on the server side, that is, the implementation of the business logic part.
1. MVC design idea
MVC in English is Model-View-Controller, which separates the input, processing, and output processes of an application according to Model, View, and Controller. In this way, an application is divided into three layers - model layer, View layer, control layer.
View (View) represents the user interaction interface. For web applications, it can be summarized as an HTML interface, but it may be XHTML, XML and Applet. As applications grow in complexity and scale, handling interfaces becomes challenging. An application may have many different views. The MVC design pattern's processing of views is limited to the collection and processing of data on the views, as well as user requests, and does not include the processing of business processes on the views. The processing of business processes is handed over to the model. For example, an order view only accepts data from the model and displays it to the user, and passes input data and requests from the user interface to the control and model.
Model: It is the processing of business processes/states and the formulation of business rules. The processing of the business process is a black box operation for other layers. The model accepts the data requested by the view and returns the final processing result. The design of the business model can be said to be the most important core of MVC. The currently popular EJB model is a typical application example. It further divides the model from the perspective of application technology implementation in order to make full use of existing components, but it cannot be used as a framework for application design models. It only tells you that designing according to this model can utilize certain technical components, thereby reducing technical difficulties. For a developer, he can focus on the design of the business model. The MVC design pattern tells us that the application model is extracted according to certain rules. The level of extraction is very important. This is also the design basis for judging whether the developer is excellent. Abstraction and concreteness cannot be too far apart, nor too close. MVC does not provide a model design method, but only tells you that these models should be organized and managed to facilitate model reconstruction and improve reusability. We can use object programming as an analogy. MVC defines a top-level class and tells its subclasses that you can only do these, but there is no way to limit what you can do. This is very important for programming developers.
There is another very important model in the business model, which is the data model. The data model mainly refers to the data storage (persistence) of entity objects. For example, save an order to the database and get the order from the database. We can list this model separately, and all database-related operations are limited to this model.
Control (Controller) can be understood as receiving requests from users, matching models and views together, and jointly completing user requests. The role of dividing the control layer is also very obvious. It clearly tells you that it is a distributor, what kind of model is selected, what kind of view is selected, and what kind of user requests can be completed. The control layer does not do any data processing. For example, when a user clicks a connection and the control layer accepts the request, it does not process the business information. It only passes the user's information to the model, tells the model what to do, and selects a view that meets the requirements to return to the user. Therefore, one model may correspond to multiple views, and one view may correspond to multiple models.
The separation of model, view and controller allows a model to have multiple display views. If the user changes the model's data through a view's controller, all other views that depend on that data should reflect those changes. Therefore, whenever any data changes, the controller notifies all views of the change, causing the display to update. This is actually a model change-propagation mechanism. The relationship between the model, view, and controller and their respective main functions are shown in Figure 1.

2. Implementation of MVC design pattern
ASP.NET provides a good similar environment for implementing this classic design pattern. Developers implement views by developing user interfaces in ASPX pages; controller functions are implemented in logical function code (.cs); models usually correspond to the business part of the application system. Implementing this design in ASP.NET provides a multi-layer system that has obvious advantages over systems implemented with the classic ASP structure. Separating the user display (view) from the action (controller) improves code reusability. Separating the data (model) from the actions (controllers) that operate on it allows you to design a system that is independent of storing data behind the scenes. By its very nature, the MVC structure is a way to solve the problem of coupled systems.
　2.1 View
A view is a representation of a model that provides a user interaction interface. Using multiple user widgets that contain a single display page, complex Web pages can display content from multiple data sources, and web developers and artists can independently participate in the development and maintenance of these Web pages.
Under ASP.NET, the implementation of views is very simple. Page development can be completed directly in the integrated development environment by dragging controls just like developing the WINDOWS interface. This article introduces that each page adopts the form of a composite view, that is: a page is composed of multiple subviews (user parts); the subview can be the simplest HTML control, server control or Web customization composed of multiple nested controls. controls. Pages are defined by templates. The template defines the layout of the page, the labels and number of user components. The user specifies a template, and the platform automatically creates pages based on this information. For static template content, such as site navigation, menus, and friendly links on the page, the default template content configuration is used; for dynamic template content (mainly business content), due to different user requests, only post-binding can be used. The display content of the user component is filtered according to different users. It enhances reusability and prototypes the layout of your site using composed pages composed of user widgets configured from templates.
The general processing flow of the view part is as follows: First, the page template defines the layout of the page; the page configuration file defines the specific content of the view tag (user component); then, the page is initialized and loaded by the page layout strategy class; each user component It is initialized according to its own configuration, loads the validator and sets parameters, as well as event delegation, etc.; after the user submits it and passes the verification of the presentation layer, the user component automatically submits the data to the business entity, that is, the model.
This part mainly defines the WEB page base class PageBase; the page layout strategy class PageLayout, which completes the page layout and is used to load user components to the page; the user component base class UserControlBase, which is the user component framework, is used to dynamically load inspection components, and Enable personalization of user widgets. In order to achieve the flexibility of WEB applications, many configuration files are also used in the view part. For example, configuration files include template configuration, page configuration, path configuration, verification configuration, etc.
　2.2 Controller
To be able to control and coordinate the processing of multiple requests per user, the control mechanism should be managed in a centralized manner. Therefore, controllers are introduced for the purpose of centralized management. The application's controller centrally receives the request from the client (typically a user running a browser), decides what business logic function to perform, and then delegates the responsibility for generating the next step in the user interface to an appropriate view component.
Use the controller to provide a centralized entry point for controlling and processing requests. It is responsible for receiving, intercepting and processing user requests; and delegating the request to the distributor class to determine the view presented to the customer based on the current status and the results of the business operation. . In this part, HttpReqDispatcher (distributor class), HttpCapture (request capturer class), Controller (controller class), etc. are mainly defined, and they cooperate with each other to complete the functions of the controller. The request capturer class captures the HTTP request and forwards it to the controller class. The controller class is the initial entry point into the system for handling all requests. After the controller completes some necessary processing, it delegates the request to the distributor class; the distributor class distributor is responsible for the management and navigation of views. It manages which view will be selected to be provided to the user and provides control of distribution resources. In this part, design patterns such as distributor, strategy, factory method, and adapter are used respectively.
To enable request capturer classes to automatically capture user requests and process them, ASP.NET provides a low-level request/response API that enables developers to use .NET Framework classes to serve incoming HTTP requests. To do this, you must create a class that supports the System.Web.IHTTPHandler interface and implements the ProcessRequest() method: the request capture class, and add the class in the section of web.config. Each incoming HTTP request that ASP.NET receives is ultimately handled by a specific instance of a class that implements IHTTPHandler. The IHttpHandlerFactory provides a structure that handles the actual parsing of URL requests for IHttpHandler instances. HTTP handlers and factories are declared in the ASP.NET configuration as part of the web.config file. ASP.NET defines an configuration section where handlers and factories can be added and removed. Subdirectories inherit settings from HttpHandlerFactory and HttpHandler. HTTP handlers and factories are the mainstay of the ASP.NET page framework. The factory assigns each request to a handler, which handles the request. For example, in the global machine.config file, ASP.NET maps all requests for ASPx files to the HttpCapture class:
＜httphandlers＞
...
...
＜/httphandlers＞
　2.3 Model
Models in MVC systems can be conceptually divided into two categories