Кто кого должен создавать
1) Presenter создает View
2) View создает Presenter
3) View и Presenter создается кем-то третьим (кем?)

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
R>2) View создает Presenter
R>3) View и Presenter создается кем-то третьим (кем?)

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

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
В этом случае усложнится автоматическое тестирование. Если Presenter будет создавать View через new, то вообще умрёт.
Значит придётся создавать View через фабрику, а в unit тестах подсовывать mock объекты.

R>2) View создает Presenter
Уже лучше.

R>3) View и Presenter создается кем-то третьим (кем?)
Dependency Injection framework-ом. Например такой сценарий. XxxView принимает в конструктор IXxxPresenter. XxxView создаётся через фабрику предоставляемую DI framework-ом, экземпляр реализующий IXxxPresenter создастся автоматически и будет передан в конструктор XxxView.

Ed.ward

ИМХО, создаваться, а лучше резовиться из контейнера, должен только презентер, т.к. он заведует бизнес логикой и (под)меняться не может, т.е. является ключевым звеном/точкой для работы с данными/операцией/etc. Вью это всего навсего представление и их может быть десятки, и уж они точно не должны ничего знать о презентере или знать (если лень делать по нормальному), то только через интерфейс.

У меня так:
Views:
IView

IOrderView : IView

OrderView : IOrderView — кастомная вью, регистрируется в IoC контейнере.
{
event EventHandler<OrderInfoArgs> SaveOrder; — точка взаимодействия вью с внешним миром, в том числе и со своим презентером.
}

Presenters:
IPresenter<TView> — все интерфейсы презентеров наследуются от него.
where TView : IView

IOrderPresenter : IPresenter<IOrderView>

OrderPresenter : PresenterBase, IOrderPresenter
{
void ShowView(IRegion region)
{
var view = Container.Resolve(ViewType);
view.SaveOrder += OnSaveOrder();
}
}

Usage:
var orderPresenter = Container.Resolve<IOrderPresenter>();
var region = create region...
orderPresenter.ShowView(region);

Т.е. приложение резолвит презентер и показывает его в регионе (по аналогии с Призмой) => презентер резолвит вьюху и подписывается на события.
Это дает 1) возможность, имея один код презентера, подменять вьюхи для, например, веб и десктопной версии приложения 2) легкое тестирование с моками 3) практически нулевая связность между частами приложения и т.п. и т.д.

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
Почему бы и нет
R>2) View создает Presenter
Плохо, view должен только отображать. Приложением строится как модель данных, представления фигурируют в минимально необходимом объёме. Идеальный вариант — никто ничего не знает о представлениях, отображение строит отдельный движок. Оперируем исключительно моделями данных.
R>3) View и Presenter создается кем-то третьим (кем?)
Включает в себя 1ый вариант, наиболее гибкий подход. Идея в том, что вводится дополнительная абстракция IViewLocator, инкапсулирующая логику создания представления по презентеру. Эта абстракция умеет строить представление по модели данным

interface IViewLocator
{
    object GetView(Presenter presenter);
}

Как она то делает — по конфигу, по соглашениям, вызывает специальный метод презентера (например CreateView()) или использует все возможные варианты — определяется потребностями проекта.

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
R>2) View создает Presenter
R>3) View и Presenter создается кем-то третьим (кем?)

Этого, увы, никто не знает. Текущая рабочая породигма — все действующие лица создаются в main(). Связи устанавливаются либо там же (делегаты/интерфейсы) либо в самих объектах (отдельный middleware для связи типа OSGI).

Здравствуйте, Eye of Hell, Вы писали:

EOH>Здравствуйте, Ryadovoy, Вы писали:

R>>Кто кого должен создавать
R>>1) Presenter создает View
R>>2) View создает Presenter
R>>3) View и Presenter создается кем-то третьим (кем?)

EOH>Этого, увы, никто не знает. Текущая рабочая породигма — все действующие лица создаются в main(). Связи устанавливаются либо там же (делегаты/интерфейсы) либо в самих объектах (отдельный middleware для связи типа OSGI).
Сам то понял что написал?

Здравствуйте, Eye of Hell, Вы писали:

EOH>Этого, увы, никто не знает. Текущая рабочая породигма — все действующие лица создаются в main(). Связи устанавливаются либо там же (делегаты/интерфейсы) либо в самих объектах (отдельный middleware для связи типа OSGI).

OSGi вообще не для этого.

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
R>2) View создает Presenter
R>3) View и Presenter создается кем-то третьим (кем?)

Решение MFC

CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
        IDR_MAINFRAME,
        RUNTIME_CLASS(CMyDoc),
        RUNTIME_CLASS(CMainFrame),       // main SDI frame window
        RUNTIME_CLASS(CMyView));

CSingleDocTemplate — некий интегратор
CMyDoc — документ (presenter)
CMainFrame — основное окно
CMyView — view

Последние два — следствие структуры MFC-приложений, в которых view есть child-окно от основного.

И решению этому 20 с хвостиком лет...

Здравствуйте, Ryadovoy, Вы писали:

R>Кто кого должен создавать
R>1) Presenter создает View
R>2) View создает Presenter
R>3) View и Presenter создается кем-то третьим (кем?)


Конечно третий вариант. Все должно создаваться контейнером, который будет зависимости искать.

View получает экземпляр Presenter и делает ему SetView(this).