So far, we have looked at lots of concepts such as the Dispatcher servlet, request mapping, controllers, and the view resolver, but it would be good to see the overall picture of the Spring MVC request flow so that we can understand each component's responsibilities. But before that, you need a basic understanding of the Model View Controller (MVC) concept. Every enterprise level application's Presentation layer can be logically divided into three major parts:

The following diagram should help you to understand the event flow and command flow within an MVC pattern.

The classic MVC pattern

Whenever a user interacts with the view by clicking on a link or button, or something similar, the view issues an event notification to the controller and the controller issues a command notification to the model to update the data. Similarly, whenever the data in the model is updated or changed, a change notification event is issued to the view by the model, and in response the view issues a state query command to the model to get the latest data from the model. Here, the model and view can directly interact. This pattern is called the classic MVC. But what Spring MVC employs is something called the Web MVC pattern because of the limitation in the HTTP protocol.

In Web MVC, every interaction between the model and view are done via controllers only. So the controller acts as a bridge between the model and the view. There is no direct interaction between the model and the view as in the classic MVC.