Model View Controller
So far, we have seen lots of concepts, such as the dispatcher servlet, request mapping, controllers, and view resolver; it would be good to see the overall picture of the Spring MVC request flow so that we can understand each component's responsibilities. However, before that, we need to understand the Model View Controller (MVC) concept some more. Every enterprise-level application's presentation layer can logically be divided into the following three major parts:
- The part that manages the data (Model)
- The part that creates the user interface and screens (View)
- The part that handles interactions between the user, user interface, and data (Controller)
The following diagram will help you 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, 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 gets updated or changed, a change notification event is issued to the view by the model in response, and the view issues a state query command to the model to get the latest data from the model. Here, the model and view can interact directly; this pattern is called the classic MVC pattern. However, what Spring MVC employs is something called a web MVC pattern due to the limitations in the HTTP protocol.
Tip
Web applications rely on the HTTP protocol, which is a stateless pull protocol. This means that no request implies no reply; every time, we need to request the application to know its state. The MVC design pattern requires a push protocol for the views to be notified by the model. So in web MVC, the controller takes more responsibility for the state changing, state querying, and change notification.
In web MVC, every interaction between the model and view is taken through the controller only. So, the controller acts as a bridge between the model and view. There is no direct interaction between the model and view, as in the classic MVC pattern.