MVP (Supervising Controller) Does the view update the model?

Question

I've been reading about MVP, specifically Supervising Controller. One thing I'm having difficulty wrapping my head around is how the View interacts with the Model.

It was my understanding that the Presenter should update the Model and that the View reads from the Model. The Presenter can also update the view through an interface. Martin Fowler's article on this seems to show just that (http://martinfowler.com/eaaDev/SupervisingPresenter.html).

However, other articles/blogs show the view updating the model directly (https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-separated-presentation-patterns/).

I know these are just patterns so there will be different implementations, but the view updating the model seems like it is doing much more than it should.

Say for instance I had a person class that contained a name and phone number. The view can display this name and number and a submit button to change the name and number of the person. When the submit button is clicked I would expect the updating to be handled in the Presenter not the View. However, the article I referenced proposes that the view can directly update the model.

So, should the view ever update the model? Or should that only be handled by the Presenter?

EDIT:

Code from the MSDN article:

public class PersonalDataView : UserControl, IPersonalDataView
{
    protected TextBox _firstNameTextBox;

    public void SetPersonalData(PersonalData data)
    {
        _firstNameTextBox.Value = data.FirstName;
    }

    public void UpdatePersonalData(PersonalData data)
    {
        data.FirstName = _firstNameTextBox.Value;
    }
}

Answer 1

There are several variants of the MVP around since its original design in 1996 by Mike Potel. Martin Fowler discusses some of them in another article on GUI architecture.

One of the key differences between the variants is whether the view is totally isolated from the model or not:

• In the first case, the presenter is the man in the middle of a "passive view" and the model.
• In the second case, the presenter is a "supervising controller", but there are interactions directly between the view and the model. Potel's paper describe well the kind of interactions: the view can request data from the model, and the model can notify the view of some events.

In none of the case would the view directly change the model. The change of the model goes always via the Presenter (or the controller in an MVC).

Remark 1: The MSDN article shows only one arrow directly from the view to the model, in its introduction on the MVC (Model View Controller) part. The arrow is in the wrong direction, but the text is correct: the view can access to the model, and change itself (i.e. not the model, but redraw itself) upon change of the model's data.

Remark 2: The MSDN article also shows Microsoft's MVVM pattern, which is roughly a MVP, but the presenter is ambiguously called "ViewModel". But again, the View therein doesn't updated the model directly.

Your edit:

The code of your edit shows a bidirectional data binding, where update of data in the view would trigger directly a change in the model. This indeed contradicts the original MVP pattern where the View informs the Presenter of desired changes via an "Interactor" and the Presenter has the monopoly to invoke "Commands" to update the Model.

Remark 3: I think the author of this MSDN blog was more interested in introducing the MVVM architecture than writing a comprehensive in-depth article, like Martin Fowler did, on the other architectures. I think also that Microsoft's ADO databinding architecture dating back to the early days of the .net framework favored such a mixed design and made a classic MVP less trivial to implement (it required a DataObjectSource to isolate data model access).

Answer 2

From Fowler's Supervising Presenter article which you linked in your question:

Factor the UI into a view and controller where the view handles simple mapping to the underlying model and the the controller handles input response and complex view logic.

It says clearly that for all simple tasks the view can talk directly to the model. So it doesn't contradict the MSDN article. This is exactly because for simple mapping/binding of properties you don't need to involve another layer as this would just complicate things without much benefit.

Again, Fowler talks about this at the end of the article:

[...] the driving issue is how much behavior to leave in the view. Passive View is a very similar pattern to Supervising Controller, but with the difference that Passive View puts all the view update behavior in the controller, including simple cases. This results in extra programming, but does mean that all the presentation behavior is testable. The choice between the two depends on what kind of Data Binding support you have and whether you're happy to leave that untested by controller tests.

You should keep in mind a few things:

• Make sure that at all times the model is the "master" of it's data. This means that the View never should write directly to the fields of the model (anyway a bad idea). Properties is ok if your language supports them. This way, the model can still react on any updates to its data (e.g. by calculating another field).
• Don't couple your model to the view. The model must be independently testable and in principle you should be able to change the view without affecting the model. This means the model should never directly call the view. Use interfaces, or probably best here, the Observer pattern. The View can subscribe itself to the model for updates.
• Never put any (business) logic into the View. If you find yourself writing if statements in the view code, think about whether those should rather belong into the presenter or model.