When the request leaves the browser, it carries information about what the user is asking for. At very least, the request will be carrying the requested URL. But it may also carry additional data such as the information submitted in a form by the user.

The first stop in the request’s travels is Spring’s DispatcherServlet . Like most Java-based MVC frameworks, Spring MVC funnels requests through a single front controller servlet. A front controller is a common web-application pattern where a single servlet delegates responsibility for a request to other components of an application to perform the actual processing. In the case of Spring MVC, DispatcherServlet is the front controller.

        The DispatcherServlet’s job is to send the request on to a Spring MVC controller. A controller is a Spring component that processes the request. But a typical application may have several controllers and DispatcherServlet needs help deciding which controller to send the request to. So, the DispatcherServlet consults one or more handler mappings C to figure out where the request’s next stop will be. The handler mapping will pay particular attention to the URL carried by the request when making its decision.

        Once an appropriate controller has been chosen, DispatcherServlet sends the request on its merry way to the chosen controller. D At the controller, the request will drop off its payload (the information submitted by the user) and patiently wait for the controller to process that information. (Actually, a well-designed Controller performs little or no processing itself and instead delegates responsibility for the business logic to one or more service objects.)

The logic performed by a controller often results in some information that needs to be carried back to the user and displayed in the browser. This information is referred to as the model. But sending raw information back to the user isn’t sufficient—it needs to be formatted in a user-friendly format, typically HTML. For that the information needs to be given to a view, typically a JSP.

       So, the last thing that the controller will do is package up the model data and the name of a view into a ModelAndView object.  It then sends the request, along with its new ModelAndView parcel, back to the DispatcherServlet. As its name implies, the ModelAndView object contains both the model data as well as a hint to what view should render the results.

       So that the controller isn’t coupled to a particular view, the ModelAndView doesn’t carry a reference to the actual JSP. Instead it only carries a logical name that will be used to look up the actual view that will produce the resulting HTML. Once the ModelAndView is delivered to the DispatcherServlet, the DispatcherServlet asks a view resolver to help find the actual JSP. 

       Now that the DispatcherServlet knows which view will render the results, the request’s job is almost over. Its final stop is at the view implementation (probably a JSP) where it delivers the model data.  With the model data delivered to the view, the request’s job is done. The view will use the model data to render a page that will be carried back to the browser by the (not-so-hard-working) response object.

摘自《 Manning Spring in action》

通过对SpringMVC中request生命周期的理解。我们就很容易记住如何来配置他了。