4

Note: The example in this question is for demonstration. Please focus on the question and not on problems in the example (such as tight coupling, lack of Dependency Injection etc.).


I have a form to create a contact with a button for saving it. Here are the View and Presenter(written in C#).

View:

class View : Form
{
    Presenter presenter;
    public Contact Contact
    {
        get { /* getting logic */ }
    }

    View()
    {
        presenter = new resenter(this);

        InitializeComponent();
        SetEvents();
    }

    void SetEvents()
    {
        saveButton.Click += presenter.SaveButton_Click;
    }
}

Presenter:

class Presenter
{
    View view;
    Model model;

    Presenter(View view)
    {
        this.view = view;
        this.model = new Model();
    }

    public void SaveButton_Click()
    {

    }
}

My question is what should be written in SaveButton_Click. Should I call directly the ContactRepository:

public void SaveButton_Click()
{
    ContactRepository.Save(view.Contact);
}

Or rather create a Save method in the Model that calls ContactRepository:

public void SaveButton_Click()
{
    model.SaveContact(view.Contact);
}
.
.
.
class Model
{
    public void SaveContact(Contact contact)
    {
        ContactRepository.Save(view.Contact);
    }
}

Which is the correct way? Is the first breaking MVP principles, or the second is just creating unnecessary methods?

  • It should be handled in the presenter, the model should just represent the data that will be displayed in the view, it should contain no logic. – user1450877 Mar 27 '17 at 12:17
  • @user1450877 Could you please elaborate on that in an answer? Thanks. – Sipo Mar 27 '17 at 12:18
  • no time sorry. However try to understand that MVP is a GUI design pattern, it's scope is limited to maintaining GUI state, displaying it to the user and routing messages about user gestures. The gateway to the business logic is through the presenter. – user1450877 Mar 27 '17 at 16:18
5

In an MVP model, the presenter acts as middleman between the view and the model.

In consequence, from the presenter you shall call the model and not short- circuit it by calling repository directly.

The model has to take care of the persistance, including locking if necessary, maintaining the unit of work, caching (e.g.with an identity map) or whatever else is needed.

If you would call the repository directly, you might not be aware of all these aspects and end up with something that doesn't work as it should, or create undesired dependencies (between the presenter and the model internals), or both.

  • So the second option? – Sipo Mar 27 '17 at 12:34
  • 1
    Yes, definitively ! – Christophe Mar 27 '17 at 12:45
5

In my experience it depends on who you ask (but it shouldn't).

I've seen your question asked about MVC, MVP, and MVVM. There is confusion about all three. But why is that?

This is mainly the consequence of a misunderstandings of what the Model is.

For some, the Model is simply a dumb object that holds data. For this interpretation of Model it is clear that it can't be responsible for invoking calls to the rest of the application (eg, using a repository)

However, I would argue that this interpretation is invalid.

For example, in the MVVM world the ViewModel is responsible for gluing the model to the View. The View is responsible for interacting with the user. By process of elimination, everything else falls under the responsibility of the Model.

People frequently try to put business logic in their ViewModels, but this defeats the purpose of the MVVM pattern, which is to separate the User Interface concerns from the application concerns. Instead, the ViewModel's sole responsibility is to glue the Model (its data, functionalities, and behaviours) to the View.

I'm not an expert in MVC or MVP, but from what I understand the principles are roughly the same. The Controllers or Presenters are facilitators and not doers.

This means your Model must be more than just vapid data.

  • Here additional infos on the 3 architectures: martinfowler.com/eaaDev/uiArchs.html - For the mvp, i suggest to jump to the link that thir article provides to Potel's original in-depth article, which explains the rationale of the presenter (in the context of client view and server model) – Christophe Mar 27 '17 at 13:01
  • MVVM is just MVP with data-binding replacing the role of the presenter. The Model in the MVP acronym is a View Model. I think some confusion arises because there are 3 GUI patterns and MVVM is the only acronym to contain a reference to the business layer in it because the model it alludes to is a business model. – user1450877 Mar 27 '17 at 16:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.