Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what is the processing flow of Spring MVC". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. The former king-- Servlet

When the author first came into contact with the use of Java for Web development, Spring MVC is far less popular than it is today. Didn't you see the scene of the prosperity of King Servlet? In retrospect, using Servlet for development is not as easy as it is now, and there are a lot of things to do on your own, but Servlet makes the logic of development very clear, especially after Servlet and jsp take on their respective roles well, coupled with the popularity of mvc layering. Writing Web applications was a fun and simple thing at that time.

In fact, Servlet does not do a lot of things, the author thinks that what Servlet wants to complete is the process of unified request acceptance, processing and response.

One thing that cannot be bypassed in network programming is, needless to say, everyone's guess: Socket. But if the network needs to transmit, it is very complex, first of all, we need to follow certain protocols. Now we generally use Http and Https to transmit data, while Socket shields the details of the underlying protocols on top of some network protocols, and provides users with a unified api. But Servlet thinks that Socket is not doing enough, or that we have to deal with it accordingly. So Servlet (in the case of HttpServlet), he encapsulates the request message in the network into Request representation, which is HttpServletRequest in the process of Http communication, and uniformly encapsulates the response returned by the server after processing the request into a HttpServletResponse object.

What are the benefits of this?

As developers, we no longer have to do the tedious things of dealing with web requests and responses, but only need to focus on our business logic development.

Have you found that every time the improvement of the efficiency of the framework is to separate the most important business logic from other tasks as completely as possible, so that we can always devote ourselves to the development of business logic? Spring AOP is not a good proof!

So how do you use Servlet?

Students who have no experience of using Servlet can listen to me briefly:

1. First we usually write our own Servlet and inherit it from HttpServlet, then rewrite its doGet () and doPost () methods. Both methods pass HttpServletRequest and HttpServletResponse as parameters, and then we extract the parameters from the front end from the Request, call the pre-written Service API in the corresponding doXXX method, and the Dao API can prepare the data to be placed in the Response and jump to the specified page, and you can choose to forward or redirect.

2. Servlet uses the design pattern of the template method. At the top level of Servlet, the service method will be called, which will construct HttpServletRequest and HttpServletResponse objects as parameters to call the doXXX () method overridden by the subclass. Then return the request.

3. Finally, we need to register the custom Servlet we wrote with web.xml, and configure servlet-mapping in web.xml to specify which requests are processed for that servlet.

The use of Servlet is that simple! In fact, his popularity for a long time also benefited from his simplicity and ease of use.

ShoppingServlet com.myTest.ShoppingServlet ShoppingServlet / shop/ShoppingServlet 2, want to go further

When we use Servlet for business logic development, we often feel great, but also feel a little uncomfortable at the same time. The main areas of discomfort are as follows:

Each Servlet can only handle one request, so when the system is larger and the business is more complex, there may be hundreds of Servlet, which are dazzled to find.

Each time, we need to manually obtain the request parameters from the Request and encapsulate them into the objects we want, in which we may have to verify the parameters. After we call the business logic layer to obtain the data, we need to manually set it to the response and manually select forwarding or redirection to jump.

The url of our request is hard-configured into the web.xml, which lacks flexibility. It would be nice if we could dynamically configure the corresponding relationship between the request url and processing.

Our Servlet is tightly coupled with the front-end rendering framework, so when the current side changes to another display technology, we need to change the larger code. If we can separate the data processing from the data display, it will be better to make it loosely coupled.

With these thoughts, can we further extract the development of business logic?

In the early days, the author also made some attempts. The general idea is to write a BaseServlet, and then the Servlet we define inherits from BaseServlet. The request at the front end needs to specify which method of Servlet to process, so you need to take a method parameter with it, for example:

Http://localhost:8080/myProject/MyServlet?method=getInfo

In BaseServlet, the parameter information is extracted and the method of the subclass is called using the reflected method. The subclass method returns the result of the String type, which represents the name of the logical view to be returned, that is, the path to be redirected. Then the parent class gets the result and redirects it using redirection or forwarding.

At this point, some friends must be impatient, obviously talking about Spring MVC, so far there is not even a shadow of Spring MVC, all talking about Servlet. Don't worry, understanding these is of great help to our understanding of Spring MVC. Please read on.

At this point, what I really want to say is that if we want to go further on Servlet and further separate business logic from other work, then we need to build a great and painstaking,... (uh, I can't remember.) Super Servlet, to do this work for us, let's call this Servlet super awesome Servlet for the time being. And who are the big guys who developed Spring? we can think of this, but they can't think of it? So they started to develop this super awesome Servlet and officially named it DispatcherServlet.

3. Spring MVC-- two-level controller mode

Then we are about to officially start the journey of Spring MVC, through the previous understanding, we know that Spring MVC calls that super Servlet DispatcherServlet, this Servlet can be said to be worried about simplifying our development, we call it the front-end controller. Now we can't help thinking that the BaseServlet we wrote before corresponds to the current super awesome Servlet (DispatcherServlet). So what's the name of the custom Servlet that defines our business logic? Spring MVC calls the class that defines our business logic processing Handler, but it is no longer a Servlet, but an ordinary class, which is easy to understand. After all, DispatcherServlet has done too much and is so powerful that it can treat an ordinary class like Servlet, and this Handler is called secondary controller _.

There may be some friends who disagree. Some books say that the secondary controller of Spring MVC is called Controller, not Handler.

In fact, the secondary controller of Spring MVC is indeed called Handler, but Hander is abstract, and Spring MVC chooses to use Controller to implement Handler. At this point, do you think we can customize a Handler implementation called Lellortnoc? Of course the answer is yes! It is as if List is an abstract interface, and the implementation of List has ArrayList,LinkedList.

4. DispatcherServlet-- front-end controller

DispatcherServlet is the core of the whole Spring MVC, and the honorary title of Super Servlet is worthy of the name. DispatcherServlet and his family members have completed a lot of work together, including automatic binding of request parameters, automatic verification of parameters, automatic matching of request url, jump of logical view names to real pages, separation of data acquisition and data rendering display, and so on. In this process, he is more like a conductor, methodically directing the request to move forward, and finally complete the response data of the server.

If you want to understand exactly how DispatcherServlet is directed, move on! Recommended: summary of 250 interview questions

5. HandlerMapper-- requests mapping experts

Consider that when we write code in Servlet, the mapping of the request is handed over to web.xml. But now that Spring MVC adopts a two-level controller, this thorny problem must be solved.

First of all, DispatcherServlet is also a Servlet, so we should also configure the request path it handles in web.xml. So what path should be configured? We say that DispatcherServlet is called Super Serlvet, and we want it to handle all requests so that DispatcherServlet can accept the processing of all requests. Configure as follows:

Spring MVC org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:Spring-servlet.xml 1 Spring MVC / *

Now that all requests are mapped to DispatcherServlet, DispatcherServlet now has the responsibility to distribute requests to specific secondary controllers. How do you find or save this mapping of requests to specific secondary controllers? DispatcherServlet chose to ask his good friend HandlerMapping.

In HandlerMapping, a specific request url is saved to which Handler (that is, the usual Controller) should be processed. Depending on the mapping strategy, HandlerMapping probably has the following mapping lookup methods:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Org.springframework.web.servlet.handler.SimpleUrlHandlerMapping establishes a relationship between the request path and the Controller mapping, and finds the corresponding Controller.

Org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping finds the requested Controller through the class name of the Controller.

Org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping uses the defined beanName to find the Controller to be requested

Org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping finds the corresponding Controller by annotating @ RequestMapping ("/ userlist").

Presumably now the most commonly used is the fourth, directly on the corresponding Controller and its internal methods to add the corresponding comments, you can configure the request mapping, it is fragrant. Recommended: summary of 250 interview questions

6. HandlerInterceptor, an obstacle in the way of Handler

At this point, do you think that DispatcherServlet gives the requested url to HandlerMapping, HandlerMapping finds out the corresponding Controller according to the request and gives it to DispatcherServlet, and then DispatcherServlet is handed over to Controller for execution? Then To young to native, there are some small episodes. For example, we cannot hand over all requests to Handler for execution. At the very least, we should filter out unreasonable requests, such as checking Session when jumping to the page, redirecting to the login interface if the user is not logged in, and redirecting some program exceptions in a unified way, and so on, we need to intercept requests.

If you know Servlet, don't you feel a little familiar? Yes, Filter in Servlet can also intercept and filter requests, but since Spring MVC is a two-level controller structure, there are some subtle differences between HandlerInterceptor and Filter. The main difference is that HandlerInterceptor provides finer-grained interception. After all, Filter intercepts Serlvet, while HandlerInterceptor intercepts Handler (Controller). It can be shown vividly with a picture.

HandlerInterceptor.jpg

We can see from the figure that multiple HandlerInteceptor can be configured. If any one of them returns false, the request will be intercepted and returned directly.

7. Secondary controller-Handler

The front-end controller is already familiar to us, and the secondary controller, the Handler, is the class in which we really execute the business logic. Usually in Spring MVC, this Handler is what we are familiar with as Controller. This is where we call the encapsulated business logic interface. It can be said that Spring MVC has separated the business logic from other unrelated tasks more thoroughly. So let's concentrate on writing our business logic in Handler (Controller).

8. The bridge between Handler and HandlerInterceptor-- HandlerExecutionChain

As mentioned earlier, DispatherServlet resorts to HandlerMapping to map url to secondary controllers, but after DispatherServlet gives url to a specific HandlerMapping, after HandlerMapping performs a tiger-like operation, what is returned to DispaterServlet is not an executable Handler (Controller), but a HandlerExecutionChain object. So why on earth would HandlerMapping return such an object instead of a Handler object?

In fact, when you look at the picture above, have you ever wondered how HandlerInterceptor and Handler are connected? The answer is HandlerExecutionChain. It is a combination of several HandlerInterceptor and Handler. So how is it combined?

This involves the responsibility chain design pattern in the design pattern. HandlerExecutionChain strands HandlerInterceptor and Handler into an execution chain. The first request will be intercepted by the first HandlerInterceptor. If false is returned, the request will be short-circuited directly. If true is returned, then the second HandlerInterceptor will be handed over for processing. Until all HandlerInterceptor are checked and passed, the request will not reach Handler (Controller) and be handed over to Handler for formal processing. Return layer by layer after the execution is completed.

What DispatcherServlet gets is such a concatenated HandlerExecutionChain, and then executes the request sequentially.

9. The key to decoupling-- ModelAndView

At this point, the request finally comes to the corresponding Handler. What we want is that Handler only deals with the responsible business logic, while some url jumps and so on are not responsible for Handler. So DispatcherServlet uses ModelAndView to save our data and the path we want to jump to.

We call the business logic layer to get the data, encapsulate the data into ModelAndView, and set the view logical view name of the ModelAndView. As you can see from the name of the ModelAndView, it saves the data that needs to be sent to the front end after the Handler execution is completed, as well as the path that needs to be redirected. These are what DispatcherServlet needs. Recommended: summary of 250 interview questions

10. View rendering search-ViewResolver

This step is the key for Spring MVC to separate data acquisition from data display and rendering. The front end may display data in a variety of ways, either Jsp, Html, or other ways. DispatcherServlet has got the ModelAndView, which contains the response result data returned after executing the request, as well as the path of the logical view. At this time, DispatcherServlet needs to find out who can parse and render the data according to the path of the logical view.

For example, if we use the FreeMarker template engine to render data, then it is time to find the View implementation class that is qualified for the job, so the problem is, how to find it? What strategy do you use to find it? This depends on our ViewResolver.

The common search strategies are as follows:

BeanNameViewResolver: the id that resolves the logical view name to a Bean,Bean equals the logical view name.

XmlViewResolver: similar to BeanNameViewResolver, except that the target view Bean object is defined in a separate XML file, not in the main configuration file of the DispatcherServlet context

InternalResourceViewResovlver: parses the view name to a URL file, which is typically used to map the view name to a program file (such as JSP) saved in the WEB-INF directory

XsltViewResolver: resolves the view name to an URL file that specifies the XSLT style sheet

JasperReportsViewResolver:JasperReports is an open source report tool based on java, which resolves the view name to the URL corresponding to the report file.

FreeMarkerViewResolver: parsing to template files based on FreeMarker template technology

VelocityViewResolver and VelocityLayoutViewResolver: parsing to template files based on Velocity template technology

11. Data rendering-View

After the corresponding View implementation class is found by ViewResolver according to the logical view name, DispatcherServlet will give the data in ModelAndView to the View implementation class for rendering. After the View rendering is completed, the rendered data will be handed to DispatcherServlet, and then DispatcherServlet will package it into Response and return it to the front end for display.

At this point, the entire Spring MVC processing process is complete, of course, there will be support for internationalization, theme definition and settings, and so on, but these are not commonly used, Spring MVC's main processing process requires the use of these classes. You can see that DispatcherServlet plays a vital role in this process, so the core of Spring MVC is DispatcherServlet.

Finally, a flow chart is attached as a summary of the above.

This is the end of the content of "what is the processing flow of Spring MVC". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.