SPRINGMVC Technical Details MVC Introduction

Springmvc with the Tao school .Original source: Zhang Kaitao Introduction to Web MVC 1.1. Request-response model in Web development:

In the Web world, the steps are as follows:

1, Web browsers (such as IE) initiate a request, such as access to http://sishuok.com

2. The Web server (such as Tomcat) receives the request, processes the request (for example, the user adds it, saves the user), and finally produces a response (typically HTML).

3. After the Web server is processed, the content is returned to the Web client (usually our browser), and the client processes the received content (for example, the Web browser will render the HTML content it receives to show to the customer).

Therefore, in the Web world: all Web clients initiate a request, and the Web server receives, processes, and generates a response.

The general Web server is unable to proactively notify the Web client of the update content. Although there are some technologies such as server push (such as comet), and now HTML5 WebSocket can implement the Web server to actively notify the Web client.

Here we understand the request/response model for Web development, and then we look at what the standard MVC model is. 1.2. Overview of the standard MVC model

MVC model: is an architectural pattern, does not introduce new features, but helps us to develop the structure of the Organization more reasonable, so that the presentation and model separation, Process Control logic, business logic calls and display logic separation. As shown in Figure 1-2

Figure 1-2

First, let's look at the concept of the MVC (Model-view-controller) ternary group:

Model: A data model that provides the data to be presented and therefore contains data and behaviors that can be thought of as domain models or JavaBean components (including data and behavior), but are now generally separated: Value Object (data) and service layer (behavior). That is, the model provides features such as model data query and status update of model data, including data and business.

View: Responsible for the presentation of the model, generally we see the user interface, the customer wants to see things.

Controller: Receives the user request, delegates to the model to process (state change), after processing, returns the returned model data to the view, which is displayed by the view. In other words, the controller did a dispatcher's job.

From Figure 1-1 We also see that in the standard MVC model can proactively push the data to update the view (The Observer design pattern, register the view on the model, update the view automatically when the model is updated), but in web development the model is unable to proactively push the view (unable to proactively update the user interface), Because in web development is the request-response model.

Then let's look at what MVC looks like in the web, and we call it web MVC to differentiate standard MVC. 1.3. WEB MVC Overview

Model-View-controller concept as with standard MVC concepts, refer to 1.2, and let's look at the Web MVC Standard architecture, as shown in Figure 1-3:

As shown in Figure 1-3

In Web MVC mode, the model cannot proactively push the data to the view, and if the user wants the view to be updated, it needs to send another request (that is, the request-response model).

The concept is almost there, so let's take a look at the development of web-side development, and use code to demonstrate how Web MVC is implemented, and why you should use MVC as a model. 1.4, web-side development and development process

Here we simply describe the process of comparing the core, as shown in Figure 1-4

Figure 1-4

1.4.1, CGI: (Common gateway Interface) Public Gateway Interface, a scripting technology used on the Web server, written in the C or Perl language, used to receive Web user requests and processes, and finally dynamically generate responses to the user, but each request produces a process , heavy-weight.

1.4.2, Servlet: A Java EE Web Component technology, a Web component that executes on the server side, is used to receive Web user requests and processes, and finally dynamically generates responses to the user. But each request produces only one thread (and the cable pool), lightweight. And can take advantage of many Java EE Technologies (such as JDBC). The essence is to output the HTML stream inside the Java code. But the expression logic, control logic, business logic call mixed. As shown in Figure 1-5

Figure 1-5

As shown in Figure 1-5, this practice is absolutely undesirable, control logic, performance code, business logic object calls mixed together, the biggest problem is directly in the Java code output HTML, so that front-end developers can not do page style and other design and modification, even if the changes are very troublesome, This practice is therefore undesirable in practical projects.

1.4.3, JSP: (Java Server Page): A Web Component that executes on the server side, is a template page technology that runs in a standard HTML page embedded in the scripting language (now Java only). The essence is to embed Java code in the HTML code. JSP will eventually be compiled into a servlet, but it is simpler and more convenient than a pure servlet development page. But the performance logic, control logic, business logic call or mixed. As shown in Figure 1-6

Figure 1-6

As shown in Figure 1-6, this is also absolutely undesirable, the control logic, performance code, business logic object calls mixed together, but rather than directly in the servlet output HTML a little better, Front-end developers can design and modify simple page styles and so on (but if too many embedded Java scripts are difficult to modify), the actual project is undesirable.

The JSP nature or servlet will eventually generate a servlet at run time (such as Tomcat, which will be generated under the Tomcat\work\catalina\web application name \org\apache\jsp), but this makes the HTML simple point, But still control logic, performance code, business logic object calls are mixed together.

1.4.4, Model1: Can be considered as the enhanced version of JSP, can be considered as the Jsp+javabean figure 1-7 Features: Use the <jsp:useBean> standard action, automatically encapsulate the request parameters as a JavaBean component The control logic must also be executed using Java scripts.

Figure 1-7

Here we can see that using the <jsp:useBean> standard action can simplify the acquisition/creation of JavaBean, and encapsulate the request parameters to JavaBean, and then look at the Model1 architecture, as shown in Figure 1-8.

Figure 1-8 Model1 Architecture

In the MODEL1 architecture, the JSP is responsible for controlling the invocation of logic, representation logic, business Objects (JavaBean), simply simplifying the GET request parameters and encapsulating request parameters than pure JSPs. The same is not good, in the project should be strictly prohibited (or up to the use of the demo).

1.4.5, Model2: In the Java EE World, it can be considered that the Web MVC model MODEL2 architecture can actually be considered as what we call the Web MVC model, only the controller using servlet, the model adopts JavaBean, the view using JSP, as shown in Figure 1-9

Figure 1-9 Model2 Architecture

The specific code examples are as follows: from the MODEL2 architecture, you can see that the view and the model are separated, and the control logic and presentation logic are separated. But we also see serious shortcomings:

1. 1. Controller:

1. 1. 1, the control logic may be more complex, in fact, we can according to the specification, such as request parameter submitflag=toadd, we can actually call the Toadd method directly, to simplify the control logic, and each module needs a controller, resulting in control logic may be very complex;

1. 1. 2, the request parameter to the model package is troublesome, if can give the framework to do this thing, we can get liberated from it;

1. 1. 3. Select the next view, relying heavily on the servlet API, which makes it difficult or impossible to change views;

1. 1. 4, to show the view of the model data to be displayed, using the servlet API, the replacement of the view technology is also to replace, very troublesome.

1.2. Model:

1. 2. 1, this model uses JavaBean, may cause the JavaBean component class is very large, generally now the project all uses three layer structure, but does not adopt the JavaBean.

1.3. View:

1. 3. 1, is now bound in the JSP, it is difficult to change the view, such as velocity, freemarker, such as I want to support Excel, PDF view and so on.

1.4.5, service to workers: Front Controller + Application Controller + Page Controller + context that is, front Controller + Application Controller + page controllers (also known as actions) + context, is also web MVC, but the responsibility is more clear, please refer to "core Java EE design mode" and "Enterprise Application architecture Model" as shown in Figure 1-10:

Figure 1-10

The running process is as follows: Responsibilities:

Front controller: Front-end controllers, responsible for providing a unified access point for the presentation layer, thereby avoiding repetitive control logic in the MODEL2 (unified callback by the front-end controller of the corresponding functional methods, such as the front of the submitflag=login to transfer the login method) , and you can provide common logic for multiple requests (such as preparation contexts, and so on), separating the specific view and the specific functionality processing (such as login enclosing the request parameter into the model and invoking the business logic object).

Application controller: Application controllers, front-end controller separation Select specific view and specific function processing, need someone to manage, application controller is used to select specific view technology (view management) and specific function processing (Page Controller/Command object/action management), The application of a strategy design pattern can easily switch views/page controllers without affecting each other.

Page Controller: The function processing code, collecting parameters, encapsulating parameters to the model, transferring the business object processing model, returning the logical view name to the front controller (and the specific view technology decoupling), Delegated to the application controller by the front-end controller to select a specific view to show, can be the implementation of the command design pattern. The page controller is also known as a processor or action.

Context: Contextual, remember the model data that is prepared for the view in Model2, we put it directly in request (Servlet API-related), and with context, we can place the relevant data in context, which is irrelevant to the protocol (such as Servlet API) Access/Setup model data, typically implemented through the Threadlocal model.

Here, we review the evolution of the entire Web development architecture, and perhaps different web-layer frameworks differ in detail, but with the same purpose:

A clean Web presentation layer:

Separation of models and views;

The control logic in the controller is separated from the function processing (collecting and encapsulating parameters to the model object, calling the business object);

The view selection in the controller is separated from the specific view technology.

A thin Web presentation layer:

The less you do, the better, the thin, the irrelevant code should not be included;

Only responsible for collecting and organizing parameters to model objects, initiating the invocation of business objects;

The controller only returns the logical view name and the corresponding application controller to select the specific view strategy used;

Minimize the use of framework-specific APIs to ensure easy testing.

Here we understand the evolution of web MVC, and let's look at what Spring MVC is, architecture, and how to use it in a HelloWorld. Please refer to the Springmvc-chapter1 project for the specific code of this chapter. Original address: http://www.importnew.com/19331.html