Есть WinUI приложение в основу которого положен MVP c тонким view. Любой значимый(сложный) визуальный компонент имеет своего презентера. Фактически у нас есть две иерархии: иерархия презентеров и иерархия контролов(ну еще и модель, но это сейчас не важно). Есть два пути построить иерархию контролов: с помощью form designer-а или по ходу построения иерархии презентеров(т.к. по идее презентер должен отвечать за создание дочерней триады Model-View-Presenter). Второй путь идеологически более верный, но лишает меня возможности пользоваться студийным дизайнером. Первый путь более удобен, но возникает вопрос с тем, как связать две иерархии презентеров и контролов. Собственно вопрос: как сделать так, чтобы и овцы были целы и волки сыты? Т.е. и идеология не пострадала и дизайнер пригодился.

Привет, Maxim:

MVK>дизайнер пригодился.

Я может и не в тему, но скажу: так ли уж полезен дизайнер для более или менее крупных проектов?
И поясни плз, в чем проблемма при связывании двух иерархий?

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

A>Я может и не в тему, но скажу: так ли уж полезен дизайнер для более или менее крупных проектов?
Согласен — не нужны. Реально удобно ими пользоваться для прототипирования. В более-менее серьезном проекте — лучше обходиться без них. Беда в том, что есть товарищи, которые хотят его видеть и с мнением этих товарищей приходиться считаться. (На самом деле мне таки удалось убедить, что дизайнер — это есть мировое зло).

A>И поясни плз, в чем проблемма при связывании двух иерархий?
Проблема в том, что принятие решения кого и когда содавать входит в обязанности презентера, а тут получается, что тот, кого он должен создавать уже создан. Можно, конечно, изобразить событие ViewCreated и на него создавать нужный презентер, но мне это кажется несколько кривоватым. Типа яйцо появилось и пошло искать курицу, которая будет его высижывать

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

MVK>Проблема в том, что принятие решения кого и когда содавать входит в обязанности презентера

хм... Во всех примерах пишут наоборот:
Presenter presenter = new Presenter(view);

Что, в принципе, логично...
У тебя скорее может быть несколько View с одним Presenter,
чем несколько Presenter с одним View.

MVK>Типа яйцо появилось и пошло искать курицу

Если есть яйцо, значит где-то есть и курица, которая его снесла.
Если есть курица, то яйца может и не быть...

ПС
Во замудрил

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

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

MVK>>Проблема в том, что принятие решения кого и когда содавать входит в обязанности презентера

A>хм... Во всех примерах пишут наоборот:
A>Presenter presenter = new Presenter(view);

Совершенно верно. А где располагается этот код? Очевидно в другом презентере.
А откуда он взял экземпляр View? Давай немного расширим этот код и посмотрим какие могут быть варианты?

class HighLevelPresenter
{
...
   IHighLevelView view;
   IModel model;

   void CreateChildPresenter()
   {
       //Вариант 1. За создание child отвечает view уровнем выше. 
       // Т.е., например, форма должна уметь создавать экземпляр грида который на ней лежит.
       IChildView childView = view.CreateChildView();
       
       //Вариант 2. За создание view отвечает специально обученная абстрактная фабрика, 
       //которая или предоставляется как сервис презентеру верхнего уровня или просто 
       //передается презентеру верхнего уровня в конструкторе. После этого мы должны 
       //передать экземпляр view более высого уровня.
       IChildView childView = viewFactory.CreateChildView();
       view.SetChildView(childView); //эта строчка мне не особенно нравиться, но ничего лучше я пока не придумал.

       ChildPresenter presenter = new ChildPresenter(childView, model);
       ...
   }
}

A>Что, в принципе, логично...
A>У тебя скорее может быть несколько View с одним Presenter,
A>чем несколько Presenter с одним View.
Согласен. Единоначалие рулит.

A>Если есть яйцо, значит где-то есть и курица, которая его снесла.
A>Если есть курица, то яйца может и не быть...

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

MVK>А откуда он взял экземпляр View? Давай немного расширим этот код и посмотрим какие могут быть варианты?

А откуда твой HighLevelPresenter взял IHighLevelView?

?

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

A>А откуда твой HighLevelPresenter взял IHighLevelView?
Из main вестимо, который в некотором смысле у нас презентер поневоле.

A> ?
Это я завсегда с удовольствием

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

Думал над схожей проблемой.
Какой вариант в результате выбрал? Или что-нибудь иное?

MVK>

MVK>class HighLevelPresenter
MVK>{
MVK>       //Вариант 1. За создание child отвечает view уровнем выше. 
MVK>       // Т.е., например, форма должна уметь создавать экземпляр грида который на ней лежит.
MVK>       IChildView childView = view.CreateChildView();
       
MVK>       //Вариант 2. За создание view отвечает специально обученная абстрактная фабрика, 
MVK>       //которая или предоставляется как сервис презентеру верхнего уровня или просто 
MVK>       //передается презентеру верхнего уровня в конструкторе. После этого мы должны 
MVK>       //передать экземпляр view более высого уровня.
MVK>       IChildView childView = viewFactory.CreateChildView();
MVK>       view.SetChildView(childView); //эта строчка мне не особенно нравиться, но ничего лучше я пока не придумал.
MVK>       ChildPresenter presenter = new ChildPresenter(childView, model);
MVK>   }
MVK>}
MVK>

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

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

GZ>Думал над схожей проблемой.
GZ>Какой вариант в результате выбрал? Или что-нибудь иное?

Когда я не так давно размышлял над подобной проблемой, решил ее так, View в своем конструкторе создает свой Presenter передавая себя в его конструктор. View может, при необходимости, иметь в интерфейсе ссылку на свой презентер (для presentera контейнера) и на вложенные View (для своего Presenter'a).

Плюсы решения — пара VP действительно пара, view без presenetr'a не существует, работа с presenter'ом инкапуслирована во view. View контейнеру почти безразлично, что есть у дочерних view и есть ли вообще, этим занимается его presenter. Который теоретически может самостоятельно управлять вложенными view.

Покритикуйте коллеги.