4

Let's say I have a form for representing a user.

When pressing the "Save" button, should a User object be:

  1. constructed by the View based on the input, then passed to the Model via the Presenter and then inserted into the database by the Model,
  2. constructed by the Model by using the View data (via the Presenter) and then inserted into the database by the Model.

Essentially, the question is whether or not the View should have access to Domain objects (such as User).

Christophe
  • 74,672
  • 10
  • 115
  • 187
Michael Haddad
  • 2,651
  • 3
  • 17
  • 27
  • 2
    I don't know exactly how it's done in MVP, but it's almost certainly more like option 2 than option 1. The view is never responsible for creating domain objects in any MV* architecture. It is only responsible for collecting data from the user so that some other object can create a domain object from that data. – Robert Harvey Nov 21 '17 at 16:26
  • @RobertHarvey - So if I have a `TextBox`, should I also have a property that encapsulates its value, and pass it to the Model via the Presenter to construct an object based on that value? – Michael Haddad Nov 21 '17 at 16:39
  • 3
    The key thing to understand about the MV* patterns is that they're mostly about getting as much logic out of the view as possible, so that you can test it without involving the view. How you get the value from the textbox to your domain object is largely up to you. Objects that sit between your UI and your domain can be very useful in composite cases like invoices (involving several domain objects), but if you just want to use the presenter to copy fields from the UI directly to a domain object, you can do that too. The Presenter is there to act as a "controller" of sorts. – Robert Harvey Nov 21 '17 at 16:43

1 Answers1

4

The key principle in the MVP architecture (initially introduced by Talligent in 1996), is that the presenter acts as middleman between the view and the model.

The underlying idea is that in a client-server architecture, the presenter could be split between the the server where the domain model is maintained, and the client that takes care of the view.

This is why you should go for option 2. All data manipulation must go via the presenter.

Note that the original MVP allows a direct link between model and view, but only for reading purpose (via a distributed notification M->V to inform that data has changed, and a remote access V->M to read data, in a subject-observer relationship). Some claim however that channelling this via the presenter would be preferred.

Christophe
  • 74,672
  • 10
  • 115
  • 187