The Spring framework works on the MVC design pattern, and provides a front controller, which handles or attains each request hitting the application. The following diagram shows how the Spring MVC handles the request, and all the components that are a part of the Spring MVC:

The following steps give us an orientation of the flow of the Spring MVC web application:

1. Each incoming request first hits the Front Controller, which is the heart of the application. The Front Controller dispatches the request to the handlers, and allows the developers to use different features of the framework.
2. Front Controller has its own WebApplicationContext, which is inherited from the WebApplicationContext root. The beans configured in the root application can be accessed and shared between the context and the Servlet instance of the application. As applicable to all the Servlets, the Front Controller gets initialized on the first request.

3. Once the Front Controller is initialized, it further looks for an XML file named servlet_name-servlet.xml under the WEB-INF folder. It contains MVC-specific components.
4. This configuration file is, by default, named XXX-servlet.xml under the WEB-INF folder. This file contains the mapping information of the URL to the controllers, which can handle the incoming request. Before Spring 2.5, the mapping was a must for the discovery of the handlers, which we don't need now. Now, we can directly use the annotation-based controllers.
5. The RequestMappingHandlerMapping interface searches all the controllers to look for the @RequestMapping annotation under @Controller. These handlers can be used to customize the way URLs are searched by customizing properties such as interceptor, defaultHandler, order, alwaysUseFullPath, urlDecode, and so on.
6. After scanning all the user-defined controllers, the appropriate controller based on URL mapping is chosen, and the appropriate method is invoked. The method selection takes place based on the URL mapping and the HTTP method that it supported.
7. After the execution of business logic written in the controller method, now it's time to generate the response. This is different from our usual HTTPResponse, as it won't be served to the user directly. Instead, the response will be sent to the Front Controller. Here, the response contains the logical name of the view, the logical name of the model data, and the actual data to bind. Usually, the instance of ModelAndView is returned to the Front Controller.
8. The logical view name is with the Front Controller, but it doesn't give any information about the actual view page to return to the user. The bean for ViewResolver configured in the XXX-servlet.xml file will be the mediator to map view name to the actual page. There is a wide range of view resolvers supported by the framework, which we will discuss shortly.
9. ViewResolver helps us get the actual view that the Front Controller can return as a response. The Front Controller will render it by extracting the values from the bounded model data, and will return it to the user.

In the flow discussion, we have used many names such as Front Controller, ModelAndView, ViewResolver, ModelMap, and so on. Let's discuss the classes in depth.