170529. Working principle and mechanism of SPRINGMVC

Working principle
Above is the schematic diagram of SPRINGMVC's work:

1, the client sends an HTTP request to the Web server, the Web server parses the HTTP request, If the request mapping path (specified in Web. xml) matches the Dispatcherservlet, the Web container will forward the request to Dispatcherservlet.

2. After receiving this request, Dipatcherservlet will find the processor (Handler) processing the request based on the requested information (including URL, HTTP method, request packet header and request parameter cookie, etc.) and handlermapping configuration.

3-4, Dispatcherservlet according to handlermapping find corresponding handler, the processing right to handler (handler will be specific processing to package), Then the specific handleradapter to the handler to make a specific call.

5, Handler will return a Modelandview () object to Dispatcherservlet after the data processing is completed.

6. Handler return Modelandview () just a logical view is not a formal view, Dispatchersevlet transforms a logical view into a real views view by Viewresolver.

7, dispatcher through the model to parse out the parameters in the Modelandview () and finally show the full view and return to the client.

What is the working mechanism?

Control Invocation (cont.)

Then for the supplement of (II): The main point is to summarize the control of the key processing logic operation;

The key to control processing is that a handler in each Handlermapping object is matched by the requested URL in the Dispatcherservlet handlermappings collection, After a successful match, the handler processing connection Handlerexecutionchain object is returned. This Handlerexecutionchain object will contain multiple user-defined Handlerinterceptor objects.

/*** Return The Handlerexecutionchain for this request.     * <p>tries All handler mappings in order. * @paramRequest Current HTTP request *@returnthe Handlerexecutionchain, or <code>null</code> if no handler could be found*/    protectedHandlerexecutionchain GetHandler (HttpServletRequest request)throwsException { for(Handlermapping HM: This. Handlermappings) {            if(logger.istraceenabled ()) {Logger.trace ("Testing handler Map [" + HM + "] in Dispatcherservlet with Name '" + getservletname () + "'"); } Handlerexecutionchain Handler=Hm.gethandler (Request); if(Handler! =NULL) {                returnhandler; }        }        return NULL; }

For the three methods defined in the Handlerinterceptor interface, Prehandler and Posthandler are executed before and after the execution of handler, aftercompletion in view rendering complete, Executes before the Dispatcherservlet returns.

PS: So what we need to note is that when Prehandler returns false, the current request will be returned directly after the aftercompletion is executed, and handler will not execute.

The GetHandler () method in the class Handlerexecutionchain is the return object;

/**      * Return The handler object to execute.      @return The handler object      */     Public Object gethandler () {        returnthis. handler;    }

There is no type of handler here, and the type of handler is determined by Handleradapter. Dispatcherservlet supports the object based on which Handleradapter instance the handler object matches in its Handleradapters collection. The next step is to execute the corresponding method of the handler object, and if the corresponding method of the handler object returns a Modelandview object, the next step is to perform the view rendering.

/**      * Return The handler object to execute.      @return The handler object      */     Public Object gethandler () {        returnthis. handler;    }

---------------------------------------the evil dividing line---------------------------------------------

Model design

If handler returns the Modelandview object, the handler needs to pass a model instance to the view to render the template. In addition to rendering pages that require model instances, there are typically model instances at the business logic level.

The Modelandview object is a bridge between the business logic layer and the view display layer, which is also a bridge connecting handler and view to spring MVC. The Modelandview object, by definition, holds the name of a Modelmap object and a View object or view. The Modelmap object is an instance of the variable that is required to perform the template rendering, such as the object that corresponds to the JSTL tag name obtained by Request.getattribute (String) in the JSP. Velocity context.get (String) Gets the variable instance corresponding to the $foo.

public class Modelandview {/** View instance or view name String */    private Object View;     /** Model MAP */    private modelmap model;     /** indicates whether or not this instance have been cleared with a call to {@link #clear ()} */    private Boolean cleared = false; ..... }

Modelmap is also a map,handler in the template will be required in this map, and then passed to the view corresponding to the viewresolver.

 Public Interface viewresolver {    throws  Exception;}

Different viewresolver will have different ways of dealing with the objects in this map.

• Velocity saves this map to Velocitycontext.
• The JSP sets each element in the Modelmap to Request.setattribute (Modelname,modelvalue) respectively;

-----------------------the evil dividing line-----------------------------------------------

View Design

In spring MVC, a view module requires two components to support: Requesttoviewnametranslator and Viewresolver

 Public InterfaceRequesttoviewnametranslator {/*** Translate the given {@linkHttpServletRequest} into a view name. * @paramrequest the incoming {@linkHttpServletRequest} providing * the context from which a view name was to be resolved *@returnThe view name (or <code>null</code> if no default found) *@throwsException If view name translation fails*/String Getviewname (httpservletrequest request)throwsException;}

For Viewresolver, the front has written to, do not write;

-----------------------the evil dividing line-------------------------------------------------

Requesttoviewnametranslator: primarily supports user-defined parsing of viewname, such as adding a prefix or suffix to the requested viewname, or replacing it with a specific string.

Viewresolver: Mainly based on the user request viewname create the appropriate template engine to render the final page, Viewresolver will create a View object based on ViewName, call the View object's void Render method render the page;

 Public Interface View {voidthrows  Exception;}

The following summarizes the logic of Spring MVC parsing view:

The Dispatcherservlet method calls the Getdefaultviewname () method;

 /**   * Translate the supplied request into a DEFA     Ult view name. *   @param   request current HTTP servlet Request *   @return   The view name (or <code& gt;null</code> if no default found) *   @throws   Exception if view name translation failed  */ protected  String getdefaultviewname (httpservletrequest request) throws   Exception { return  this  .viewnametranslator.getviewname (Request); }

The Getviewname method of Requesttoviewnametranslator was called;

 Public InterfaceRequesttoviewnametranslator {/*** Translate the given {@linkHttpServletRequest} into a view name. * @paramrequest the incoming {@linkHttpServletRequest} providing * the context from which a view name was to be resolved *@returnThe view name (or <code>null</code> if no default found) *@throwsException If view name translation fails*/String Getviewname (httpservletrequest request)throwsException;}

Call the Resolvelocale method of the Localeresolver interface;

Locale Resolvelocale (httpservletrequest request);

Call the Resolveviewname method of the Viewresolver interface to return to the View object

throws Exception;

Call the Render method to render the page

PS: Reference post address http://www.cnblogs.com/zbf1214/p/5265117.html

170529. Working principle and mechanism of SPRINGMVC