This is the 16th day of my participation in the November Gwen Challenge. Check out the event details: The last Gwen Challenge 2021

Spring MVC is a part of the Spring framework, which, like Struts, belongs to the Web layer framework. According to the idea of project layering, a project can be basically divided into persistence layer, business layer and Web layer. Spring MVC is primarily at the Web layer, also known as the presentation layer.

The core function of the Web layer is to process user requests and return data, so let’s take a look at how Spring MVC handles requests and returns data. Let’s take a look at the general flow.

The figure above shows the general direction in the framework. When the user makes a request, the front-end processor receives the request, but does not do any work itself, and sends the request to a different processor, which calls the business method for processing, and gets the result back to the front-end controller, which then sends the result to JSP to render the page. Finally, the HTML page with the results is returned to the browser.

To be more specific, first you need to tell me what requests to handle, and I will accept all of them. This requires us to configure in the web.xml file what requests to enter the framework.

The request comes in, but it’s a string of urls, and the framework needs to parse the request. The live front end controller still doesn’t parse the request, but it’s handled by the HandlerMapping. This object is provided by Spring MVC and we just need to configure it. Don’t forget the power of IoC in Spring.

What the processor mapper does is, you give me a bunch of urls, I analyze the URL, and I find the package name plus the class name plus the method name that handles the request and I return it to the controller. If you can’t find it, call 404. This mapping between urls and methods is usually configured on top of methods using the @requestMapping annotation.

You think that the controller will execute after knowing the specific method, think too much, at this time the processor adapter appears, which is the second leg of the controller, ah, it does not work, then who will deal with ah, that must be our awesome cozily programmer.

You match the URL of the method, you do not write method you also want to fly not ah!

There must be some logic that needs to be written to handle the URL. Given the package name + class name + method name, the front-end controller and the processor adapter say “go see where this method is and handle it.” Processor adapter a look, this is not the two dog son next door, and then called the two dog son, to deal with the request.

Well, here comes the real work, our lovely programmer, and, unsurprisingly, the method returns a result to the front controller. Then the boss says, “View parser, come here, give you a result, go render the result on the page. “

The view parser takes the result and the page (not necessarily a JSP, but more commonly a JSP), fills the fill, and gets an HTML page, and then these perfect binaries are sent over the network cable from a distant server to the browser for the user to see.

This is the logic for a request to be processed in the Web layer by the Spring MVC framework. Note that our hand-written processor Controller calls the Service layer, which is the scope of the business layer. For more details, see the picture below.

There are always exceptions, 404,500. To keep our users in the dark, we can also configure a global exception handling class. We only need to implement HandlerExceptionResolver. Of course, we also need to register the implementation class in Spring.

So when an exception occurs, we can set up a jump to a kawaii page, but actually the system has a problem…

Spring MVC can handle both normal and abnormal ones, but you’d think that would be enough. No, it provides a lot of other functionality.

For example, the foreground form must have encType, and the background must use the MultipartFile interface to receive the image parameters with the same parameter name, and the implementation class is still fixed. We need to inject the CommonsMultipartResolver class.

There is also the concept of interceptor, which is an embodiment of AOP programming. All we need to do is configure the interceptor path and interceptor class in the configuration file using the tag.

<mvc:interceptor> 
Copy the code

In the interceptor class we can handle the specific logic, such as verifying that the user is logged in. To the user classification ah, not the user jump page is inconsistent.

Finally, the differences between Spring MVC and Struts2.

The Spring MVC entry is a Servlet (front-end controller) and the Struts2 entry is a Filter.

2, Spring MVC is based on method development (one URL corresponds to one method), request parameters passed to method parameters, can be designed as singletons or multiple cases (suggested singletons), Struts2 is based on class development, pass parameters through the class attributes, can only be designed as multiple cases.

Struts2 uses value stack to store request and response data, access data through OGNL, Spring MVC through the parameter parser is the request content parsing, and assign values to method parameters, data and view encapsulation into ModelAndView object, Finally, the model data in ModelAndView is transferred to the page through the request domain. The Jsp view parser uses JSTL expressions by default.