Requests all sites that go through using Spring MVC
When the request leaves the browser①, it will contain information about the content requested by the user, at least the requested URL. But there may also be other information, such as form information submitted by the user. The first stop on the request journey is Spring's DispatcherServlet. Like most Java-based web frameworks, all requests in Spring MVC go through a front controller servlet. A front controller is a common web application pattern where a single-instance servlet delegates requests to other components of the application to perform the actual processing. In Spring MVC, DispatcherServlet is the front controller.
The task of the DispatcherServlet is to send the request to the Spring MVC controller. A controller is a Spring component that handles requests. In a typical application there may be multiple controllers and the DispatcherServlet needs to know which controller the request should be sent to. So DispatcherServlet will query one or more handler mappings (handler mapping) ② to determine where the next stop of the request is. The processor mapping will make decisions based on the URL information carried by the request.
Once the appropriate controller is selected, the DispatcherServlet will send the request to the selected controller ③. When it comes to the controller, the request offloads its load (the information submitted by the user) and waits patiently for the controller to process that information. (In reality, a well-designed controller handles little to no work by itself, but instead delegates the business logic to one or more service objects for processing.)
After the controller completes the logic processing, it usually generates some information, which needs to be returned to the user and displayed on the browser. This information is called a model. But it's not enough to just return raw information to the user - the information needs to be formatted in a user-friendly way, usually HTML. So, the information needs to be sent to a view, usually a JSP.
The last thing the controller does is package the model data and mark the view name for the rendered output. It next sends the request back to the DispatcherServlet along with the model and view names. ④
In this way, the controller is not coupled to a specific view, and the view name passed to the DispatcherServlet does not directly refer to a specific JSP. In fact, it doesn't even determine that the view is a JSP. Instead, it's just passed a logical name that will be used to find the actual view that produces the result. The DispatcherServlet will use the view resolver ⑤ to match the logical view name to a specific view implementation, which may or may not be a JSP.
Now that the DispatcherServlet already knows which view to render the result, the requested task is basically complete. Its last stop is the implementation of the view (probably a JSP) ⑥ where it delivers the model data. The requested task is completed. The view will render output using the model data, and this output will be passed to the client via the response object ⑦ .