The previous part is here . Original article here .

Model-View-Presenter (MVP)

The MVP architecture first appeared in IBM and more clearly manifested in the Taligent system in the 1990s. It is described in sufficient detail in the work of Potel. The idea was picked up by the developers of Dolphin Smalltalk . As we will see later, these two works say not exactly the same thing, but the idea embedded in them has become very popular. We will refer to these two sources in the description of the architecture.

To start describing MVP, I find it helpful to think about the significant differences between the two pillars of UI development. On the one hand, there are “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 understood design and allows for easy separation between reusable controls and the business code of the application. It lacks the fact that MVC is in abundance - a split view ( Separated Presentation ) and a programming context conditioned by the use of a domain model ( Domain Model ). I see MVP as the combination of these two models, as an attempt to take the best from them.

According to Potel, the presentation in MVP should be understood as the structure of the form controls in the “Forms and Elements” model, and any partitions of the control on the controller / view should be removed. The view must not contain any behavior that determines how the element interacts with the user.
')
This interaction is carried out in a separate object representation (presenter). In the view, the fundamental event handlers of the controls remain, but their purpose is to transfer control to the presenter.

The presenter must determine how to respond to the event. Potel defines this interaction in terms of model actions that occur through a system of commands and selections. By the way, you can take note of this approach - the packaging of all editions of the model in the team. It will allow you to easily enter undo / redo behavior.

The reverse update from model to view occurs through all the same synchronization through the updater ( Observer Synchronization ), which is used in MVC.

A similar description is defined in the work of Dolphin . It also requires the presence of the object presenter. However, Dolphin does not define the system of interaction between the presenter and the model. In addition, there is an unequivocal hint that the presenter object should have direct access to the presentation. Potel says nothing about whether the presenter should have access to the presentation or not, but for Dolphin this behavior is very important, just 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 the awareness of the approach with which the presenter controls the elements in the presentation. On the one hand, Potel argues that all presentation logic should be left in the presentation and the presenter should not determine the rendering of the model. Lord Bower and McGlashan offer their solution, which I call Supervising Controller . In this solution, almost all the presentation logic is also defined in the presentation, however, the presenter has the ability to influence this logic in complex scenarios. Those. some part of the presentation logic can be placed in the presenter.

In addition, you can transfer the entire presentation logic to the presenter and get what I call the 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, and now I will only say that it is a type 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 in MVP from MVC, but not in the way I see it. Potel argues that the controllers in MVC are the general coordinators - with which I disagree. Dolphin talks a lot about MVC problems, while by MVC they mean the VisualWorks application model, not the classic MVC that I was talking about. I do not blame them for this - in our time, information on the classical MVC is not very easy to get.

Now it's time to talk about the differences between MVP from previous architectures (as I see them):

• Forms and elements: in MVP there is a model and the presenter manipulates this model with the help of synchronization through the browser ( Observer Synchronization ) when updating the presentation. And although direct access to the controls of the presenter is allowed, using this access is a bad form.
• MVC: To manipulate the model, the MVP model uses the Supervising Controller . Controls pass user input to Supervising Controller . Controls are not divided into views and controllers. Presenter can be perceived as a controller, but without the initial processing of user input. It is important that the presenter is an object of the form level, rather than a control - in my opinion, this is an even greater difference.
• Application Model: Views submit events to the presenter just as they transmit them to the application model. However, the MVP view can update itself directly from the domain model, since The presenter is not a Presentation Model . In addition, the presenter can have direct access to controls, which is impossible in the case of synchronization through the browser ( Observer Synchronization ).

There is a clear similarity between the MVP presenters and the MVC controllers. Presenter is just a freer form of controller. As a result, many architectures will follow MVP paths, but will use the term “controller”, meaning presenter. Generally speaking, the controller should be used when the issue is solved with the interaction with user input at the control level.



Figure 12: Sequence diagram of updating the current value in the MVP model

Let's take a look at how the current value update works in the ice cream example (Figure 12 ). The beginning of the diagram is very similar to the one that was in the "forms and elements" - the user enters the value, the text field sends the event "text changed." The presenter listens to this event and catches it, after which it takes the new value from the view. Then it updates the domain object, which in turn is viewed by the reject text box. The deviation text box updates its value with a calculated value, after which it is assigned a color. Color appoints the presenter. It reads the measurement category of the measurement and updates the color of the text field (via a direct link to the control).

Let's summarize the MVP model:

• User interactions (events) are passed to controls in Supervising Controller , where further processing takes place.
• Presenter coordinates changes in the domain model.
• Implementation of the update views of different variations of MVP are 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 .