Martin Fowler - GUI Architectures. Part 4
The previous part is here . The original article is here .
MVP architecture first appeared at IBM and more clearly appeared on the Taligent system in the 1990s. Described in sufficient detail in sweated ( Potel ). The idea was picked up by the developers of Dolphin Smalltalk . As we will see later, these two works do not say exactly the same thing, but the idea embedded in them has become very popular. We will refer to these two sources when describing the architecture.
In order to start describing MVP, I find it useful to think about the significant differences between the two pillars of UI development. On the one hand are the “Forms and Elements”, architecture, which is the mainstream of UI design. On the other hand, MVC and its derivatives. The “forms and elements” model provides the developer with an easily understandable design and allows for easy separation between reusable controls and the application’s business code. She lacks the abundance of MVC - Separated Presentation and programming context driven by the use of the Domain Model . I perceive MVP as a combination of these two models, as an attempt to take the best from them.
According to Potel, a view in MVP should be understood as the structure of form controls in the “Forms and Elements” model, and any separation of the control into the controller \ view should be removed. The view should not contain any behavior that determines how the element interacts with the user.
This interaction is carried out in a separate object-representation (presenter). The underlying control event events remain in the view, but their purpose is to transfer control to the presenter.
Presenter must determine how to respond to the event. Potel defines this interaction in terms of actions on the model, which occurs through a system of commands and samples. By the way, you can take note of this approach - packing all the model editions into a team. It will allow you to easily enter the Undo / Redo behavior (undo / redo).
The reverse update from model to view occurs through the same synchronization through the updater ( Observer Synchronization ), which is used in MVC.
A similar description is defined by Dolphin. It also requires a presenter object. However, Dolphin does not define a presenter interaction system with a model. In addition, it clearly hints that the presenter must have direct access to the view. Potel says nothing about whether the presenter should have access to the view or not, but for Dolphin this behavior is very important, precisely because of the problem in the Application Model with the deviation color that I described in the previous section . As you remember, it was solved in such an awkward way, from my point of view.
One of the other keys to understanding MVP is understanding the approach with which the presenter controls the elements in the view. On the one hand, Potel argues that all view logic should be left in the view and presenter should not define the model. Gentlemen Bower and McGlashan offer their solution, which I call Supervising Controller . In this solution, almost all presentation logic is also defined in the presentation, however presenter has the ability to influence this logic in complex scenarios. Those. some of the presentation logic can be placed in a presenter.
In addition, you can transfer the entire presentation logic to presenter and get what I call Passive View. Initially, Passive View was not part of the MVP model. This model appeared later, when people learned to solve testing problems. I will talk about this model later, but for now I will only say that it is one of the types of MVP.
Before determining the difference between MVP and everything else that I described above, I would like to say a few words about the works I mention. They determine the difference between MVP and MVC, but not in the way I see it. Potel claims that the controllers in MVC are the common coordinators - which I disagree with. Dolphin talks a lot about MVC issues, and by MVC they mean the VisualWorks application model, not the classic MVC that I talked about. I do not blame them for this - in our time, information on the classic MVC is not very easy to get.
Now is the time to talk about the differences between MVP and previous architectures (as I see them):
There is a clear similarity between the MVP presenter and the MVC controllers. Presenter is just a looser form of controller. As a result, many architectures will follow the MVP paths, but they will use the term “controller”, referring to presenter. Generally speaking, you need to use the controller when the issue of interacting with user input at the control level is resolved.
Figure 12: Current value update sequence diagram in the MVP model
Let's see how the current value update works in the ice cream example (Figure 12) The beginning of the diagram is very similar to the one in the “forms and elements” - the user enters a value, the text field sends an event “text changed”. Presenter listens to this event and catches it, after which it takes a new meaning from the presentation. Then it updates the domain object, which in turn is reviewed by the rejection text field. The deviation text field updates its value with the calculated value, after which it is assigned a color. Color designates presenter. It reads the deviation category of the measurement and updates the color of the text field (via a direct link to the control).
To summarize the MVP model:
The next part is here .
Model-View-Presenter (MVP)
MVP architecture first appeared at IBM and more clearly appeared on the Taligent system in the 1990s. Described in sufficient detail in sweated ( Potel ). The idea was picked up by the developers of Dolphin Smalltalk . As we will see later, these two works do not say exactly the same thing, but the idea embedded in them has become very popular. We will refer to these two sources when describing the architecture.
In order to start describing MVP, I find it useful to think about the significant differences between the two pillars of UI development. On the one hand are the “Forms and Elements”, architecture, which is the mainstream of UI design. On the other hand, MVC and its derivatives. The “forms and elements” model provides the developer with an easily understandable design and allows for easy separation between reusable controls and the application’s business code. She lacks the abundance of MVC - Separated Presentation and programming context driven by the use of the Domain Model . I perceive MVP as a combination of these two models, as an attempt to take the best from them.
According to Potel, a view in MVP should be understood as the structure of form controls in the “Forms and Elements” model, and any separation of the control into the controller \ view should be removed. The view should not contain any behavior that determines how the element interacts with the user.
This interaction is carried out in a separate object-representation (presenter). The underlying control event events remain in the view, but their purpose is to transfer control to the presenter.
Presenter must determine how to respond to the event. Potel defines this interaction in terms of actions on the model, which occurs through a system of commands and samples. By the way, you can take note of this approach - packing all the model editions into a team. It will allow you to easily enter the Undo / Redo behavior (undo / redo).
The reverse update from model to view occurs through the same synchronization through the updater ( Observer Synchronization ), which is used in MVC.
A similar description is defined by Dolphin. It also requires a presenter object. However, Dolphin does not define a presenter interaction system with a model. In addition, it clearly hints that the presenter must have direct access to the view. Potel says nothing about whether the presenter should have access to the view or not, but for Dolphin this behavior is very important, precisely because of the problem in the Application Model with the deviation color that I described in the previous section . As you remember, it was solved in such an awkward way, from my point of view.
One of the other keys to understanding MVP is understanding the approach with which the presenter controls the elements in the view. On the one hand, Potel argues that all view logic should be left in the view and presenter should not define the model. Gentlemen Bower and McGlashan offer their solution, which I call Supervising Controller . In this solution, almost all presentation logic is also defined in the presentation, however presenter has the ability to influence this logic in complex scenarios. Those. some of the presentation logic can be placed in a presenter.
In addition, you can transfer the entire presentation logic to presenter and get what I call Passive View. Initially, Passive View was not part of the MVP model. This model appeared later, when people learned to solve testing problems. I will talk about this model later, but for now I will only say that it is one of the types of MVP.
Before determining the difference between MVP and everything else that I described above, I would like to say a few words about the works I mention. They determine the difference between MVP and MVC, but not in the way I see it. Potel claims that the controllers in MVC are the common coordinators - which I disagree with. Dolphin talks a lot about MVC issues, and by MVC they mean the VisualWorks application model, not the classic MVC that I talked about. I do not blame them for this - in our time, information on the classic MVC is not very easy to get.
Now is the time to talk about the differences between MVP and previous architectures (as I see them):
- Forms and Elements: MVP has a model and presenter manipulates this model using Observer Synchronization when it updates the view. And although direct access to the presenter’s controls is allowed, using this access is bad form.
- MVC: To manipulate a model, the MVP model uses a Supervising Controller . The controls pass user input to the Supervising Controller . Controls are not divided into views and controllers. Presenter can be thought of as a controller, but without the initial processing of user input. The important thing is that presenter is an object of the form level, rather than the control - in my opinion, this is an even bigger difference.
- Application Model: Views pass events to the presenter just like they pass them to the application model. However, the view in MVP can update itself directly from the domain model, as presenter is not a model of presentation ( Presentation Model ). In addition, presenter can have direct access to the controls, which is not possible in the case of synchronization via the browser ( Observer Synchronization ).
There is a clear similarity between the MVP presenter and the MVC controllers. Presenter is just a looser form of controller. As a result, many architectures will follow the MVP paths, but they will use the term “controller”, referring to presenter. Generally speaking, you need to use the controller when the issue of interacting with user input at the control level is resolved.
Figure 12: Current value update sequence diagram in the MVP model
Let's see how the current value update works in the ice cream example (Figure 12) The beginning of the diagram is very similar to the one in the “forms and elements” - the user enters a value, the text field sends an event “text changed”. Presenter listens to this event and catches it, after which it takes a new meaning from the presentation. Then it updates the domain object, which in turn is reviewed by the rejection text field. The deviation text field updates its value with the calculated value, after which it is assigned a color. Color designates presenter. It reads the deviation category of the measurement and updates the color of the text field (via a direct link to the control).
To summarize the MVP model:
- User interaction (events) are transmitted by the controls to the Supervising Controller , where further processing takes place.
- Presenter coordinates changes to the domain model.
- The implementation of updating views with different variations of MVP is carried out in different ways. The number of methods starts from updating through the browser ( Observer Synchronization ) and ends with manual updates of each presenter control.
The next part is here .