MVC pattern
The MVC pattern is the abbreviation for "Model-view-controller", and the Chinese translates to "mode-view-controller". MVC applications are always made up of these three parts. Event causes the controller to change the model or view, or to change both. As long as the controller changes the data or attributes of the models, all dependent view will be updated automatically. Similarly, as long as the controller changes the View,view will retrieve the data from the potential model to refresh itself. The MVC pattern was first proposed by the Smalltalk language research group and applied to user interaction applications. There are many similarities between the Smalltalk language and the Java language, both object-oriented languages, and it is natural for sun to recommend the MVC pattern as an architectural model for developing Web applications in the Petstore (pet store) case application. The MVC pattern is an architectural pattern that requires other modes of collaboration to complete. In the Java EE Pattern directory, the service to worker pattern is typically implemented, and the service to worker mode can be composed of a centralized controller mode, a dispatcher mode, and a page helper mode. While struts only implements the MVC view and controller two parts, the model part needs to be implemented by the developer themselves, and struts provides an abstract class action that enables developers to apply model to the Struts framework. The MVC pattern is a complex architectural pattern, and its implementation is very complex. However, we have ended up with a number of reliable design patterns, combined with multiple design patterns, making the MVC pattern implementation relatively straightforward. Views can be thought of as a tree, which can obviously be achieved with composite pattern. The relationship between views and models can be embodied by observer pattern. Controller controls the display of views, can be implemented with strategy pattern. The model is usually a mediator and can be implemented using mediator pattern.
Now let's take a look at where the three parts of MVC are located in the Java EE architecture, which helps us understand the MVC pattern implementation. The relationship between MVC and the Java EE architecture is that the view is in Web tier or client tier, usually Jsp/servlet, which is the page display section. The controller is also in the Web Tier, usually implemented with Servlets, which is the logical part of the page display. The model is in middle Tier, usually implemented with the service-side JavaBean or EJB, which is the business logic part.
First, MVC design ideas
MVC English is Model-view-controller, that is, an application of input, processing, output process according to model, view, Controller to separate the way, such an application is divided into three layers-model layer, view layer, control layer.
The view represents the user interface, which can be generalized as an HTML interface for Web applications, but it can be XHTML, XML, and applets. With the complexity and scale of the application, the processing of the interface becomes challenging. An application may have many different views, the MVC design pattern is limited to the processing of the view's data collection and processing, and the user's request, not including the business process on the view. The processing of business processes is delivered to the model. For example, an order view only accepts data from the model and is displayed to the user, as well as passing input data and requests from the user interface to the control and model.
Model: The processing of business processes/States and the development of business rules. The processing of business processes is a black box 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 main core of MVC. The current popular EJB model is a typical application example, it makes a further division of the model from the angle of application technology implementation, in order to make full use of the existing components, but it cannot be used as the framework of application design model. It simply tells you that you can use some of the technical components as a result of this model, which reduces technical difficulties. For a developer, you 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, and the level of abstraction is very important, which is also the design basis to judge whether the developers are excellent. Abstract and concrete cannot be too far apart, nor too close. MVC does not provide a design approach to the model, but only tells you that you should organize and manage these models to facilitate the refactoring of the model and improve reusability. We can use object programming to make metaphors, and MVC defines a top-level class that tells its subclasses that you can only do this, but there's no limit to what you can do. This is important for developers of programming.
The business model also has a very important model that is the data model. The data model mainly refers to the data preservation (persistence) of the entity object. For example, save an order to a database and get an order from a database. We can list this model separately, and all operations on the database are limited to that model.
The control (Controller) can be understood as receiving requests from the user, matching the model to the view, and collectively completing the user's request. The function of dividing the control layer is also obvious, it clearly tells you that it is a dispatcher, choose what kind of model, choose what kind of view, what kind of user request can be completed. The control layer does not do any data processing. For example, when a user clicks on a connection, the control layer accepts the request and does not process the business information, it only passes the user's information to the model, tells the model what to do, and selects the view that meets the requirements to return to the user. Therefore, a model may correspond to multiple views, and one view may correspond to multiple models.
The separation of models, views, and controllers allows a model to have multiple display views. If a user changes the model's data through a view's controller, all other views that depend on the data should be reflected in these changes. Therefore, whenever any data changes occur, the controller notifies all views of the change, causing the updates to be displayed. This is actually a model of the change-propagation mechanism. The relationships between models, views, and controllers, and their main functions, are shown in 1.
Second, the implementation of MVC design pattern
Asp. NET provides a similar environment for implementing this classic design pattern. The developer implements the view by developing the user interface in the ASPX page, the function of the controller is implemented in the logical function code (. cs), and the model usually corresponds to the business part of the application system. The implementation of this design in ASP. A multilayer system, which has obvious advantages over the system of the classic ASP architecture. The user display (view) is separated from the action (Controller), which improves the reusability of the code. Separating the data (model) from the Action (Controller) of its operation allows you to design a system that is independent of the data stored in the background. As far as the nature of MVC structure is concerned, it is a method to solve the problem of coupling system.
2.1 views
A view is a representation of a model that provides a user interface. With multiple user parts that contain a single display page, a complex web page can show content from multiple data sources, and the Web page staff, artists, can participate in the development and maintenance of these web pages alone.
Under ASP. NET, the implementation of the view is simple. Page development can be done directly in the integrated development environment by dragging controls, just as you would develop the Windows interface. Each page is described in the form of a composite view: A page consists of multiple sub-views (user parts); A child view can be a Web custom control that is nested within the simplest HTML control, server control, or multiple controls. The page is defined by the template, the template defines the layout of the page, the label and number of user parts, the user specifies a template, and the platform automatically creates the page based on that information. For static template content, such as site navigation on the page, menu, friendly links, these use the default template content configuration, for dynamic template content (mainly business content), because the user's request is different, can only use late binding, and for the user's different, the user part of the display content filtering. It enhances reusability and prototypes the layout of the site using a combination of pages that are composed of user parts based on the template configuration.
The general process of the View section is as follows: first, the page template defines the layout of the page, the page profile defines the specific contents of the view label (the user part), and the page layout policy class initializes and loads the pages, each user part initializes according to its own configuration, loads the validator and sets the parameters, As well as the delegate of the event; After the user submits, through the validation of the presentation layer, the user part automatically submits the data to the business entity as the model.
This part mainly defines the Web page base class pagebase, the page layout policy class pagelayout, completes the page layout, is used to load the user part to the page, the user part base class Usercontrolbase namely the user part frame, is used for the dynamic loading inspection part, and personalization of user parts. In order to achieve the flexibility of Web applications, the View section also uses a number of configuration files such as: template configuration, page configuration, path configuration, authentication configuration, and so on.
2.2 Controller
To be able to control and coordinate the processing of each user across multiple requests, the control mechanism should be managed in a centralized manner. Therefore, the controller is introduced in order to achieve the purpose of centralized management. The application's controller set receives the request from the client (typically a user running the browser), decides what business logic functions to perform, and then delegates responsibility for the next user interface to an appropriate view component.
The controller provides a centralized entry point for controlling and processing requests, which is responsible for receiving, intercepting, and processing user requests, and delegating the request to the Distributor class, which determines the view that is presented to the customer based on the current state and the results of the business operation. In this section, we mainly define the Httpreqdispatcher (Distributor Class), the Httpcapture (request-capturing class), the controller (Director Class), and so on, and they cooperate with each other to complete the functions of the controller. The request capture class captures the HTTP request and forwards it to the Controller class. The Controller class is the initial entry point for all requests that are processed in the system. The controller completes some necessary processing to delegate the request to the Distributor class, and the Distributor class Distributor is responsible for the management and navigation of the view, which manages which view will be selected for the user and is provided to the distribution resource control. In this section, the Distributor, strategy, factory method, adapter and other design patterns are adopted respectively.
To enable the request-capture class to automatically capture user requests and process them, ASP. NET provides a low-level request/response API that enables developers to service incoming HTTP requests using the. NET Framework class. To do this, you must author a class that supports the System.Web.IHTTPHandler interface and implement the ProcessRequest () method, that is, the request-grabber class, and add the class in the ...
...
2.3 Models
The models in the MVC system can be conceptually divided into two categories
http://www.bkjia.com/PHPjc/632486.html www.bkjia.com true http://www.bkjia.com/PHPjc/632486.html techarticle MVC pattern MVC pattern is model-view-controller abbreviation, Chinese translation for mode-view-controller. MVC applications are always made up of these three parts. Event (events) cause controll ...
