Где должны родиться View & Presenter - PullRequest
Новая
       7

Где должны родиться View & Presenter

5 голосов
/ 10 декабря 2008

Теперь я полностью понимаю паттерн MVP, но мне все еще трудно увидеть, где создаются экземпляры представлений и докладчиков. Я видел несколько примеров, когда докладчик обновлялся в представлении, но это правильно. После прочтения в блоге сообщения Джереми Миллера о связи между View и Presenter у него появилась функция Presenter, чтобы прикрепить докладчика к представлению.

Тогда у меня такой вопрос: где должны создаваться представления и докладчики? Также где в winforms и webforms.

Ответы [ 3 ]

3 голосов
/ 10 декабря 2008

В веб-формах страница создается по запросу. Поскольку страница является представлением, и вы не можете управлять порядком ее выполнения, именно представлению необходимо зарегистрироваться у ведущего

2 голосов
/ 10 декабря 2008

В Winforms я создаю экземпляр представления по мере необходимости (например, в методе main или в методе другого докладчика, но везде, где это действительно имеет смысл). Затем представление создает и регистрирует себя с новым экземпляром презентатора.

Это облегчает использование нескольких представлений, использующих одну и ту же логику презентатора, и ограждает пользователей моего представления от моего конкретного архитектурного решения использовать MVP.

1 голос
/ 18 января 2013

Во-первых, хороший вопрос. Во-вторых, это может не иметь большого значения. Мое личное предпочтение - почти всегда подключать Presenter и View в представлении.

Сравните этот сценарий: 

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

к этому: 

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

Как вы видите, у последнего гораздо меньше дублирования кода. Конечно, это глупое дублирование, или вы могли бы сказать, что можете переместить обычную функциональность в совместно используемую функцию, но вы понимаете, что это только пример. Именно тогда у вас будет один и тот же вид, который будет создан в нескольких частях вашего приложения.

Кроме того, преимущество View в знании Presenter заключается в том, что вам нужно ссылаться только на Presenter в вашем проекте View, поэтому вы можете повторно использовать один и тот же Presenter в разных приложениях пользовательского интерфейса. В противном случае вам нужно будет ссылаться на каждый проект View в Presenter.

Но что важнее, так это посмотреть, как разные модели подходят для вашего случая. Если честно, даже больше возможностей. Смотрите этот дубликат вопроса.

...