The job of the DispatcherServlet is to take an incoming URI and find the right combination of handlers (generally methods on Controller classes) and views (generally JSPs) that combine to form the page or resource that's supposed to be found at that location.
I might have
/WEB-INF/jsp/pages/Home.jsp
and a method on a class
@RequestMapping(value="/pages/Home.html")
private ModelMap buildHome() {
return somestuff;
}
The Dispatcher servlet is the bit that "knows" to call that method when a browser requests the page, and to combine its results with the matching JSP file to make an html document.
How it accomplishes this varies widely with configuration and Spring version.
There's also no reason the end result has to be web pages. It can do the same thing to locate RMI end points, handle SOAP requests, anything that can come into a servlet.
In Spring MVC, all incoming requests go through a single servlet. This servlet - DispatcherServlet
- is the front controller. Front controller is a typical design pattern in the web applications development. In this case, a single servlet receives all requests and transfers them to all other components of the application.
The task of the DispatcherServlet
is to send request to the specific Spring MVC controller.
Usually we have a lot of controllers and DispatcherServlet
refers to one of the following mappers in order to determine the target controller:
BeanNameUrlHandlerMapping
;ControllerBeanNameHandlerMapping
;ControllerClassNameHandlerMapping
;DefaultAnnotationHandlerMapping
;SimpleUrlHandlerMapping
.If no configuration is performed, the DispatcherServlet
uses BeanNameUrlHandlerMapping
and DefaultAnnotationHandlerMapping
by default.
When the target controller is identified, the DispatcherServlet
sends request to it. The controller performs some work according to the request
(or delegate it to the other objects), and returns back to the DispatcherServlet
with the Model and the name of the View.
The name of the View is only a logical name. This logical name is then used to search for the actual View (to avoid coupling with the controller and specific View). Then DispatcherServlet
refers to the ViewResolver
and maps the logical name of the View to the specific implementation of the View.
Some possible Implementations of the ViewResolver
are:
BeanNameViewResolver
;ContentNegotiatingViewResolver
;FreeMarkerViewResolver
;InternalResourceViewResolver
;JasperReportsViewResolver
;ResourceBundleViewResolver
;TilesViewResolver
;UrlBasedViewResolver
;VelocityLayoutViewResolver
;VelocityViewResolver
;XmlViewResolver
;XsltViewResolver
.When the DispatcherServlet
determines the view that will display the results it will be rendered as the response.
Finally, the DispatcherServlet
returns the Response
object back to the client.
I know this question is marked as solved already but I want to add a newer image explaining this pattern in detail(source: spring in action 4):
Explanation
When the request leaves the browser (1), it carries information about what the user is asking for. At the 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 at Spring’s DispatcherServlet. Like most Java- based web 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 per- form 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 some help deciding which controller to send the request to. So the DispatcherServlet consults one or more handler mappings (2) to figure out where the request’s next stop will be. The handler mapping pays 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 (3). At the controller, the request drops off its payload (the information submitted by the user) and patiently waits while the controller processes that information. (Actually, a well-designed controller per- forms 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 suffi- cient—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 JavaServer Page (JSP). One of the last things a controller does is package up the model data and identify the name of a view that should render the output. It then sends the request, along with the model and view name, back to the DispatcherServlet (4). So that the controller doesn’t get coupled to a particular view, the view name passed back to DispatcherServlet doesn’t directly identify a specific JSP. It doesn’t even necessarily suggest that the view is a JSP. Instead, it only carries a logical name that will be used to look up the actual view that will produce the result. The DispatcherServlet consults a view resolver (5) to map the logical view name to a spe- cific view implementation, which may or may not be a JSP. Now that DispatcherServlet knows which view will render the result, the request’s job is almost over. Its final stop is at the view implementation (6), typically a JSP, where it delivers the model data. The request’s job is finally done. The view will use the model data to render output that will be carried back to the client by the (not- so-hardworking) response object (7).
DispatcherServlet
is Spring MVC's implementation of the front controller pattern.
See description in the Spring docs here.
Essentially, it's a servlet that takes the incoming request, and delegates processing of that request to one of a number of handlers, the mapping of which is specific in the DispatcherServlet
configuration.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With