SpringMVC lifecycle-- the overall view

Question

I'm way new to Spring.

I am looking to verify the following understanding of SpringMVC lifecycle-- to put things into places in the overall view:

The entire process is request-driven.

There is a Front Controller pattern and the Front Controller in Spring MVC is DispatcherServlet.

Upon every incoming request from the user, Spring manages the entire life cycle as described in here.

In the overall view, DispatcherServlet dispatches the request to a controller for a service at the back-end. Once this is done, it hands it in to the View component of MVC for its view to be prepared in response to the user.

In more detail,

• DispatcherServlet uses Handlers to decide "which controller" to serve that request.

• The controllers are/should be "light-weighted"-- should be decoupled from the service processes at back end as a good design practice-- they hold references to the service(s) and invoke the right one(s). Their "mission" is to control the service process(es) for building the model and handing it back to the dispatcher for the next step.

• The View component in itself has 2 parts: first the ViewResolver picks the right type of look for View to put the model into the final format for the user.

From the developer's angle-- the DispatcherServlet is a behind-the-scenes thing. All i do is to define, and configure it, if necessary, in web.xml. As the developer, I instantiate an ApplicationContext (there are many ApplicationContext types-- i pick one depending on what i need, typically the WebApplicationContext(?) ). AplicationContext is the factory that creates all the servlets/beans including the DispatcherServlet, using their descriptions in the .xml files. The DispatcherServlet then runs behind the scenes and manages the entire process-- goes&gets the controllers, using the annotations or the their .xml descriptions, views, handlers, validators etc.

I am wondering whether this description is holds-- valid&complete, and whether there are big missing pieces in it.

Thanks in advance.

Answer 1

Let's go into detail step by step

DispatcherServlet uses Handlers to decide "which controller" to serve that request

The DispatcherServlet maintains an ordered List of HandlerMapping beans (which it loaded from the WebApplicationContext). A HandlerMapping is

Interface to be implemented by objects that define a mapping between requests and handler objects.

When the DispatcherServlet receives a request, it iterates over this list until it finds a matching handler object for the request in question. For simplicity, let's consider only RequestMappingHandlerMapping.

A bean of this type stores a mapping of @RequestMapping annotated methods (the actual Method object retrieved with reflection) stored as a HandlerMethod instances and wrapped in RequestMappingInfo objects that hold mapping data for matching the request, ie. URL, headers, and request parameters.

The DispatcherServlet retrieves the best matching HandlerMethod from these and any corresponding HandlerInterceptor instances which you may have registered. It retrieves these as a HandlerExecutionChain object. It will first apply any pre-handling by HandlerInterceptors. It will then try to invoke your HandlerMethod. This will typically (but not always) be a @RequestMapping annotated method inside a @Controller annotated class. This produces what Spring calls a dispatch result. The DispatcherServlet then applies post-handling by the HandlerInterceptors. It finally processes the dispatch result depending on what it is. You can see the supported return types for an idea of what that can be.

The controllers are/should be "light-weighted"-- should be decoupled from the service processes at back end as a good design practice-- they hold references to the service(s) and invoke the right one(s). Their "mission" is to control the service process(es) for building the model and handing it back to the dispatcher for the next step.

In an MVC application, the controller controls operations by making changes to the model. You can do this directly in your controller or you can decouple it by implementing and providing service and business classes for that purpose. The controller depends on these, but not the other way around. Check out multilayered architectures.

The controller then builds the model (Model) which the DispatcherServlet possibly makes available to the view. I say possibly because the controller can produce a response directly without any view (think jsp) involved.

The View component in itself has 2 parts: first the ViewResolver picks the right type of look for View to put the model into the final format for the user.

In the typical case where the Controller handler method would return a Model, View, ModelAndView, String (and some others) object, then a ViewResolver would handle finding the correct View. The DispatcherServlet then tries to render that view by first merging the model as you said. This usually means taking all Model attributes and putting them into the HttpServletRequest attributes. The rendering step can involve rendering a jsp, generating XML, or anything at all really.

From the developer's angle-- the DispatcherServlet is a behind-the-scenes thing. All i do is to define, and configure it, if necessary, in web.xml. As the developer, I instantiate an ApplicationContext (there are many ApplicationContext types-- i pick one depending on what i need, typically the WebApplicationContext(?) ).

You don't actually need to instantiate it. The DispatcherServlet will do that itself (or use the ContextLoaderListener's) when the Servlet container calls init() on it. It will generate its own WebApplicationContext. What you can do is decide which subclass of WebApplicationContext to use. This is an important choice if you want to load your context from XML or from a Java configuration. You can do this by providing an <init-param>.

AplicationContext is the factory that creates all the servlets/beans including the DispatcherServlet, using their descriptions in the .xml files. The DispatcherServlet then runs behind the scenes and manages the entire process-- goes&gets the controllers, using the annotations or the their .xml descriptions, views, handlers, validators etc.

The ApplicationContext is also known as the Inversion of Control Container. It does not include the DispatcherServlet. The DispatcherServlet is managed by the Servlet container and not by Spring. However, it does primarily take its configuration from Spring's ApplicationContext (WebApplicationContext). It registers a number of special beans it finds in the context. You can declare these yourself or let Spring do it for you with this little bit of XML

<mvc:annotation-driven>

This will (mostly) take care of doing what you describe, ie. registering handlers, validators, views, etc.

I am wondering whether this description is holds-- valid&complete, and whether there are big missing pieces in it.

Don't forget that a Spring MVC web application is a Servlet web application. The lifecycle of the application is therefore tied to the Servlet container.