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

Spring has been analyzed before the IOC ("zero basic belt you see Spring source code-IOC control inversion") and AOP ("start from the source code, an article with you to understand Spring AOP aspect-oriented programming") source code, this time to analyze the SpringMVC. This article first briefly describes the current use of SpringMVC, and then through the simplicity of Demo to let you have a preliminary impression of use, and then take an impression to see the implementation of the distribution source code.

What exactly is Spring MVC? are we still using it?

Spring MVC, the official name is actually the package name on Spring Web MVC,Maven is also spring-webmvc. Since the birth of Spring, it has been a Servlet Api-based web architecture. It is worth mentioning that at the time of Spring5, a new Web architecture, Flux, is based on an event-driven model (similar to nodejs). I will write an article to introduce Flux in the future. Please follow us.

MVC can be said to be the most popular front-end interaction model in the last century. It includes Model (business model), View (user view) and Controller (controller). It organizes each part separately, and the treatment of code abstraction and isolation is a model of code design.

However, since the beginning of 15 years, with the rise of various front-end frameworks, the relationship between the front-end and the back-end has further evolved, from the MVC architecture to the front-end and back-end separate REST architecture. In the past, every request of the MVC architecture had to go through the flow of controller-> model-> view, which evolved into a REST architecture in which the front end requests the back-end interface and returns JSON.

The question is, are we still using SpringMVC? The answer is, not all. The front and back ends are separated from the code and deployment, that is, the back end is not aware of the front end, so for the back end, the View (user view) is out of the question. Model (business model) sends a change in nature, which used to be a front-end Model needed to read to the page, but now a JSON format is given to the front-end, which is handled freely by the front-end.

As the core of the Web framework, the Controller (controller) is still there. So now people use more Controller layer to use SpringMVC. Of course, SpringMVC has other components, including filter, Http Caching, Web Security, and so on. This article only focuses on the functions of Controller in the MVC architecture, while the core component of Controller is DispatcherServlet. So later we'll take a closer look at how DispatcherSevlet controls the distribution of requests through Demo.

A brief introduction of traditional SpringMVC Startup

In traditional SpringMVC, you need to configure web.xml and applicationContext.xml. The former is the configuration responsible for configuring project initialization, such as servlet, welcome pages, etc., which is the specification of JavaEE. The latter is the configuration that initializes Spring Context, mainly the configuration of Bean.

As mentioned earlier, SpringMVC is based on Servlet architecture, while DispatcherServlet is the Servlet that SpringMVC intercepts to process all requests, so web.xml needs to configure DispatcherServlet. Others are contextLoaderListener, which is responsible for loading all context content except DispatcherServlet, and you also need to specify Spring configuration files (such as applicationContext.xml) through contextConfigLoader.

So when the project starts, loading web.xml will first execute contextLoaderListener and have it initialize the Application context of Spring. If a HTTP request comes in, it will fall on the DispatcherServlet and let it do the processing and distribution.

SpringBoot Web Demo building

Since the advent of Spring configuration annotations and SpringBoot, fewer and fewer people have written web.xml and applicationContext.xml configuration files. However, in order to facilitate the direct understanding of the principle of Dispatcher, Demo is directly built with SpringBoot's starter.

Add web's starter dependency directly

Org.springframework.boot spring-boot-starter-web 2.0.4.RELEASE

Take a look at what this starter contains

The green box is the dependency of springMVC, the red box is the dependence of Spring automatic configuration, and the blue box is the dependency of embedded tomcat. The version of Spring is 5.0.8 RELEASE.

SpringBoot startup class

Test controller

After starting the project, type http://localhost:8080/hello?name=Zack in the browser. The result returns Hello Zack.

These are the basics of using SpringMVC now. Let's take a look at how SpringMVC uses DispatcherServlet to intercept and distribute.

DispatcherServlet source code analysis

When a request comes in, it executes various filter first, filters out the final required request, and then falls into the doService () method in the DispatcherServlet. The method is to set some special request parameters in advance and then forward them to doDispatch () for real processing and forwarding.

Take a look at the notes for doDispatch ().

The purpose of this method is to execute the handler actually distributed to.

The Handler is obtained through the priority of the HandlerMapping. HandlerAdapter is obtained by querying the loaded HandlerAdapter of DispatcherServlet and supporting the Handler. All HTTP requests are processed by doDispatch (). Exactly which method to deal with the business logic depends on HandlerAdapters or handlers.

As can be seen from the comments, the core of the whole distribution logic lies in HandlerAdapter and Handler. So what on earth are these two?

Instructions on the official website

HandlerAdapter assists DispatcherServlet to call the corresponding handler, ignoring how the specific handler is called. For example, calling an annotated controller requires processing annotations, and a xml configuration needs to parse the configuration file. The purpose of this adapter is to help DispatcherServlet block out the details of processing.

There is no clear explanation for Handler, but we debug source code can find that Handler is actually assigned to the specific methods that need to be dealt with (compare the red box below with the controller of Demo above).

Going back to the source code of the doDispatch () method, you can see that getHandler () and getHandlerAdapter () are where you get Handler and HandlerAdapter.

GetHandler ()

Take a look at getHandler () source code

The whole method is only a few lines, but there are two points to note. One is that the method returns a HandlerExecutionChain type instead of a Handler.

HandlerExecutionChain is actually a layer of encapsulation of Handler, and it also contains interceptor interceptors corresponding to Handler, which are used to perform some pre-and post-operations of Handler.

Another point, HandlerExecutionChain comes out by traversing the handlerMappings in order. And what is HandlerMapping?

From the description of the official website, we can see that it is an associated Map between request and handler (actually HandlerExecutionChain). In popular terms, it is the association between routing and processing logic. It has two main implementations, one is RequestMappingHandlerMapping (which supports annotated form methods), and the other is SimpleUrlHandlerMapping (maintaining and displaying registered URI resources).

It can be inferred that when the Spring starts, the annotated, registered static resources are scanned to initialize the handlerMappings. The specific logic is in the initHandlerMappings method in DispatcherServlet.

In the initialization method, there are three main steps:

Extract the Bean of the HandlerMapping from the ApplicationContext of Spring and prioritize the Bean extracted above, mainly the @ Order annotation. If the Bean cannot be extracted from the above, the default policy is used.

For the default policy in the third point, you can find the file DispatcherServlet.properties, which is configured with some default HandlerMapping, HandlerAdapter, and other related classes.

After initializing the handlerMappings, if a request comes in, the subsequent request compares the requested route with the HandlerMapping, and finally finds the Handler (HandlerExecutionChain).

GetHandlerAdapter ()

After taking out the actual processed Handler, you need to use it to find out the support its adapter (HandlerAdapter). According to the previous description of HandlerAdapter, for Demo, the Handler of support must be RequestMappingHandlerAdapter.

This logic is also very simple, traversing the initialized handlerAdapters (the initialization process is similar to handlerMappings), and then for each handlerAdapter, call its support () method to see if it supports it.

The supports () method is also simple, using instanceof to determine whether handler is a class supported by Adapter itself.

HandlerAdapter.handle ()

After getting the Handler and HandlerAdapter, you can execute the handle method in HandlerAdapter, which is actually calling the method of Handler.

Let's follow the Demo example and take a look at the handle () method implementation of HttpRequestHandlerAdapter.

In this method, we use HttpServlet's Request and Reponse to call the methods in our own controller. It is important to note that this method returns ModelAndView, but we no longer use it based on the Rest architecture, so the method returns null.

Pre-and post-processing of Handler

As mentioned earlier, Handler is encapsulated in HandlerExecutionChain, which also contains some front-and-back interceptors. So before and after the execution of HandlerAdapter.handle (), there will be a call to HandlerExecutionChain to execute the interceptor method for pre-and post-processing.

The specific implementation is to execute the preHandle () and postHandle () methods of interceptor.

Looking back, what will be included in the pre-and post-processing here? There are three implementation classes on the HandlerInterceptor comments, namely, UserRoleAuthorizationInterceptor (check user permissions), LocaleChangeInterceptor (modify local time), and ThemeChangeInterceptor (modify current theme). You can see that HandlerInterceptor is basically some preprocessing and result encapsulation of the request.

Summary

This is the basic process of DispatcherServlet in SpringMVC. Let's sum up the above:

The architectural evolution of the front and rear ends has led to a change in the use of SpringMVC, with more emphasis on "C". The core of "C" is in DispatcherServlet's doDispatcher () method. Using request routing, compare getting handler and handlerAdapter from initialized handlerMappings and handlerAdapters. Handler is encapsulated in HandlerExecutionChain, which also includes the front and rear interceptor of handler. Finally, using the adapter pattern, the HandlerAdapter.handle () method is called to execute the business logic specifically processed by handler. The interceptor encapsulated in HandlerExecutionChain is executed before and after the execution of the specific business logic.

For more technical articles and wonderful practical information, please follow us.

Blog: zackku.com

Official account of Wechat: Zack says code

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.