MVP Design Pattern – Does the View Update the Model?

designdesign-patternsmvpobject-oriented-design

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;
    }
}

Best Answer

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).

Related Topic