1. handlermapping has a very simple definition: public interface handlermapping {handlerexecutionchain gethandler (httpservletrequest request) throws exception;} It is not based on the request URL path to obtain the corresponding handlerexecutionchain. For example, if my URL is a string of http: // localhost: 8080/blog/xiecc.htm requesturl, "/xiecc.htm" is obtained ", check each handlermapping again (remember that we have injected all handlermapping from the configuration file during initialization ), if we find "/xiecc.htm" in a simpleurlhandlermapping, I can immediately get the corresponding controller and a group of intercetpors. It is a handlerexecutionchain. The following is a class diagram of handlermapping:
1. handlermapping
The definition of handlermapping is very simple:
Public interface handlermapping {
Handlerexecutionchain gethandler (httpservletrequest request) throws exception;
}
It is not based on the request URL path to obtain the corresponding handlerexecutionchain.
For example, my URL is http: // localhost: 8080/blog/xiecc.htm.
The requesturl string is intercepted and "/xiecc.htm" is obtained ", check each handlermapping again (remember that we have injected all handlermapping from the configuration file during initialization ), if we find "/xiecc.htm" in a simpleurlhandlermapping, I can immediately get the corresponding controller and a group of intercetpors. It is a handlerexecutionchain.
The following is a class diagram of handlermapping:
It seems a little troublesome. It is actually quite simple. I will not analyze the specific classes. Its core is: It's all about hashmap.
Do you still remember handlermapping that we use most frequently in spring MVC? Is simpleurlhandlermapping. When we configure it, the core structure is hashmap. Haha! Everything is in hashmap. As long as the key of hashmap is found through URL analysis, for example, "/xiecc.htm", no get method can be used.
In the spring configuration file, we can configure multiple handlermapping, which will be found one by one until the Controller matching the URL is found. Otherwise, null is returned.
2. handlerexecutionchain
As I mentioned earlier, handlerexecutionchain is a controller and a group of interceptors. This is the most basic unit for executing a request.
However, the actual situation may be slightly different. handlerexecutionchain actually includes an object and a group of interceptor. This object is an adaptor. It can be an adaptor of the Controller or another class. But in reality, we generally use controller, so we don't need to analyze it in detail. Here we use adaptor, which greatly reduces the readability of the Code, in exchange for non-tightly coupled flexibility with the Controller. At least I do not think this is too value.
3. Controller
Controller is the core unit of spring MVC execution and an important part of self-completion by programmers. People who have used spring MVC should be familiar with it. Therefore, no specific analysis is required. The following is its class diagram:
Let's take a look at the class diagram. This is a typical application of the template method. The biggest advantage of controller is that it uses the template method to break down the controller into sub-classes of different functions. Do you want to populate the items in the request to a bean? Simply inherit simpleformcontroller. Do you want to write multiple methods in controller? Use multiactioncontroller. These controllers are designed to cover all aspects, but some people will get bored because there are too many class layers in the controller. Oh, as you like.
However, no matter how ever-changing these controllers are, they all implement a unified controller interface, which enables dispatchaction to call it without knowing the details of the controller, the power of interface.
Data Binding in the controller is also worth studying. It's fun, but this time it's not enough.
4. interceptor
The interceptor interface is defined as follows:
Public interface handlerinterceptor {
Boolean prehandle (httpservletrequest request, httpservletresponse response, Object Handler)
Throws exception;
Void posthandle (
Httpservletrequest request, httpservletresponse response, Object Handler, modelandview)
Throws exception;
Void aftercompletion (
Httpservletrequest request, httpservletresponse response, Object Handler, exception ex)
Throws exception;
}
I will not analyze the details. We just need to remember the three hook points of interceptor (join point in AOP, haha): Before the controller is executed, after the controller is executed, after the page is displayed.
5. viewresolver
Viewresolver is an interesting role that implements two functions: one is to configure the correspondence between the view and the actual page name, second, the view Factory (this is a standard factory model. Each viewresolver is responsible for producing its own view ).
The following is the definition of the viewresolver interface:
Public interface viewresolver {
View resolveviewname (string viewname, locale) throws exception;
}
Viewresolver has been configured for all people who have used spring MVC, so it is not detailed here.
I divided attributes into two categories: page file configuration, including prefix and suffix, and properties injected into the view as the view factory, such as contenttype.
The following is a class chart of viewresolver:
6. View
View is the place where the page is actually displayed. Its interface is as follows:
Public interface view {
Void render (MAP model, httpservletrequest request, httpservletresponse response) throws exception;
}
In fact, this is a simple task. Give me a hashmap and a page URI. It is not a small case to display this page. However, the difference between the display of different views on the page is quite big. for JSP, I just need to fill in the content in the hashmap in the request, and then hand it over to requestdispatcher for forward; if it is velocity, fill in the content in hashmap in the context of veloticy, and then merge the elements generated by the Template into the writer of response. Of course, there is a view in PDF or XLS. I have no time to study it. If you are interested in it any day, let's take a look at it. The following is a view class diagram:
After writing this article, I finally understood what it is called a low eye. I was hoping to write it in an abstract way, but I finally found that what I wrote is not very different from the source code analysis of the general sequential account. It is difficult to convert abstract things into concrete things from concrete to abstract things. However, our understanding can be greatly improved only after such conversions, our level can be improved.