MVP Pattern: How does the model ask for a View?

0
votes

I'm having troubles while implementing the MVP pattern. To explain it easy:

I have a WinForm (the View) who implements an interface (its corresponding IView). I have also a the presenter and, at last, the model.

But at the beginning, there was no IView, nor Presenter nor Model. There was one huge View that made everything. And so refactoring began...

Everything went fine, almost perfect. But now, I met this situation and a question about design came to me:

I found the view has a method which takes over of an event. This method is very big and have lots of logic. So I just put all the method in the presenter to free the view of logic. Everything was quite ok.

But then, I wanted to free the presenter from this logic and charge the model with it... because that logic were business rules!

I started doing this, and then I realized something: in some places this logic was asking me to instantiate other WinForms.

Now comes the question: If the presenter doesn't know anything about business rules, he shouldn't know when to instantiate a WinForm or not. So who knows? The Model, of course. But...

  1. How can the model tell somebody which View (and when) to instantiate?
  2. Who should be this "somebody"?
  3. Am I alright when I say the presenter should not know when and which view to create? Only tell the IView implementation to do it, only if somebody asks for it (maybe the model).

Thank you all!

2
c#winformsdesign-patternsmvp
I'm not sure if this helps, but I think you mean MVC, where you have MVP. If so, then it's the controller that informs the model, and is the "glue" between the model and the view. Good luck on your project :-) Here's a link for more info: tomdalling.com/blog/software-design/… – Jacob Topping
Thanks Jacob, but I actually mean MVP. The Model in the MVP involves the Controller and the Model of the MVC, as I understand. MVP only decouples the View from the Model through the Presenter. (that why de presenter should not know business rules). But thanks anyway! ;) – Nachokhan

2 Answers

1
votes

1) I see 2 ways to do this:

  • Declare events on the model, have the view(or presenter) subscribe the events and when the logic on the model decides it needs to start a view the model just triggers the event and the view calls the new view
  • Use delegates. When you call the model from your view just pass delegates that have the code to initialize the views it may need and when the logic on the model decides it needs to start a view the model just calls the delegates

2) The presenter

3) If the display if of a view is dependent on business logic then yes the presenter should not be doing the decision

1
votes

How can the model tell somebody which View (and when) to instantiate?

It's not the model's job. Keep responsibilities clear. This is application logic.

Who should be this "somebody"?

Look into the Application Controller and Event Aggregator pattern.

Am I alright when I say the presenter should not know when and which view to create? Only tell the IView implementation to do it, only if somebody asks for it (maybe the model).

The presenter should only know the view via its interface. There are times when you might need to do WinForms-specifics, but this should still be abstracted somehow. Presenters should be fully unit testable, if they start to know about concrete details, this becomes unachievable.