Where should View & Presenter be born

Question

I totally understand the MVP pattern now, but I still struggle to see where views and presenters are instantiated. I have seen some examples where the presenter is newed up in the view, but is this correct. After reading a blog post of Jeremy Miller about communicating between View and Presenter he had a function on the Presenter to attach the presenter to the view.

My question is then this: Where should views and presenters be created? Also where in winforms and webforms.

score 3 · Answer 1 · answered Dec 09 '08 at 22:15

3

In webforms, the page gets instantiated by the request. Since the page is the view and you cannot control the order of execution, it is the view that has to register itself with the presenter

answered Dec 09 '08 at 22:15

Matt Briggs

41,224
16
95
126

score 2 · Answer 2 · answered Dec 09 '08 at 22:28

2

In Winforms, I instantiate the view as required (eg: in the main method, or in a method on another presenter, but wherever makes sense really). The view then creates and registers itself with a new instance of a presenter.

This makes having several views use the same presenter logic easy, and shields users of my view from my particular architectural decision to use MVP.

answered Dec 09 '08 at 22:28

Dan Vinton

26,401
9
37
79

So, you mean your presenter will know about concrete view? – Samnang Feb 20 '09 at 10:56
1

No. The presenter has a reference to the view only through an interface that the view implements. This decouples the presenter from the view implementation, and makes unit testing presenter logic very easy since you can use a mock view for testing. – Dan Vinton Feb 21 '09 at 21:26
If you instantiate the view as required in a method on another presenter, then surely that presenter must know about the concrete view? – Feb 24 '10 at 16:26
@kevint - there's ways around that too; either have the presenter ask it's own view to create the new sub-view, or having some sort of view lookup, so the implementation returned isn't explicit. Admittedly the the answer doesn't make that too clear... – Dan Vinton Feb 24 '10 at 18:40
Ok, I see what you mean. I guess something similar to the IMessageBoxCreator in [this post](http://jeremydmiller.blogspot.com/2005/06/simple-example-of-humble-dialog-box.html) could work, only it creates screens with presenters rather than just simple dialog boxes. So you implement the IDialogCreator (which returns an IDialogView) in your presentation layer and your controllers/presenters are still blissfully unaware of the details. Thanks for the response! – Feb 24 '10 at 19:54

score 1 · Answer 3 · edited May 23 '17 at 10:34

Firstly good question. Secondly, it may not matter, much. My personal preference is to almost always wire up Presenter and View in the View.

Compare this scenario:

public class SomePresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public class AnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public class YetAnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        IContact model = new Contact();
        new ContactPresenter(model, view);
        view.Show();
    }
} 

public partial class ContactView : Form, IContactView
{    
    public ContactView()
    {
        InitializeComponent();
    }
}

to this:

public class SomePresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public class AnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public class YetAnotherPresenter
{
    public ShowContactView(IContactView view)
    {
        view.Show();
    }
} 

public partial class ContactView : Form, IContactView
{    
    public ContactView()
    {
        InitializeComponent();

        new ContactPresenter(new Contact(), this);
    }
}

As you can see that the latter has much lesser code duplication. Of course that's silly duplication or you could say you can move common functionality to a shared function, but you get the point, that's just an example.. That's when you will have the same View to be instantiated at multiple parts of your application.

Furthermore, the advantage of View knowing the Presenter is that you only need to reference Presenter in your View project, so you can re-use the same Presenter in different UI applications. Otherwise you will need to reference every View project in the Presenter..

But what's more important is to see how the different models fit your case. To be honest, there are more possibilities even. See this duplicate question.

Where should View & Presenter be born

3 Answers3