官术网_书友最值得收藏!

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:

Model View Controller

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.

主站蜘蛛池模板: 奎屯市| 招远市| 福建省| 裕民县| 津南区| 原平市| 苏尼特右旗| 廉江市| 鄢陵县| 望江县| 宁都县| 铜陵市| 丽水市| 昌黎县| 西盟| 郁南县| 克什克腾旗| 屏东市| 海晏县| 丹江口市| 安平县| 泸水县| 海安县| 苍溪县| 孟村| 霍山县| 稻城县| 神池县| 巴东县| 玛沁县| 赤峰市| 赤壁市| 东海县| 青岛市| 区。| 阿巴嘎旗| 乐平市| 云安县| 波密县| 察雅县| 弥勒县|