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

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

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

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

AN>>>>MVP с одним окошком проблем не вызывает.
AN>>>>А вот с двумя никак не придумаю, как лучше.
AN>>>>Проблема в том, что для вставки документа нужно иметь "указатель" на документ.
AN>>>>А ни интерфейсу вьюва ни презентеру "не положено знать" об используемой технологии GUI. Ну типа того — сегодня винформс, завтра впф.

Q>>>Значит нужен кто-то третий, кто все это будет знать.
AN>>Можно и третий, но проблемы остаются: будет ли команда создания окна приходить в презентер или этот третий будет всё делать сам. Или этот третий будет просто обрабатывать команду.
AN>>Что может знать этот "третий"?

Q>В моем случае команда будет приходить в презентер главного окна, он же будет создавать призентер вложенного окна, как этот презентер вложенного окна соединяется с объектом окна, смотри код выше.
Насколько я понял Ваш код там везде зависимости 1:1. Откуда знать что это вложенное окно должно попасть в определенную группу главного окна? Сейчас сделано по типу визуал студии. Окна могут быть "внизу", "слева", "справа" и "документы". При этом, сйчас я запрашиваю у главного окна активный контрол в каждой группе, если его нет создаем группу "с нуля", если есть добавляем новый к нему. То бишь нужно знать конкретную имплементацию главного окна, конкретную имлементацию активного контрола и конкретную имплементацию нового окна. Иначе всё не связать.

AN>>>>Пока приходится всё в форме делать.
AN>>>>...
AN>>>>Хотя пожалуй, только что придумал, что скажете?

AN>>>>Главная форма говорит своему презентеру "создай новое окошко".
AN>>>>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.

Q>>>Если все просто, то вполне подходящее решение. Я вообще в mvp и mvvm использую такой подход: есть служебный класс который занимается создание форм и связыванием со все остальным, его можно так же связать с ioc-контейнером. Вот примерный код:

Q>>>

Q>>>public static class WindowService
Q>>> {
Q>>>   //регистрируем тип формы и презентера. Вызывается в начале метода Main для каждого класса формы
Q>>>   public static void Register<TView,TPresenter>()
Q>>>   {
Q>>>   }
Q>>>   // отображает форму и возвращает ее объект.
Q>>>   public statiс TView Show<TPresenter,TView>(){}
Q>>> }
AN>>[#яяяя]
Q>>>  public class PresenterBase
Q>>>  {
Q>>>   private IView _view;
Q>>>   private Model _model;
   
Q>>>   public PresenterBase()
Q>>>   {
Q>>>    _view= WindowService.Show<PresenterBase,IView>();
Q>>>    _model=new Model();
Q>>>   }
Q>>>  }
Q>>>

Q>>>Просто, минимум кода, можно допилить под любые потребности.
AN>>Вообще то тут у меня вопросов больше чем ответов.
AN>>- Какого WindowService знает и "M" и "V" и "P" и "GUI"?

Q>А почему ему этого не знать, что запрещает?
Запрещает моя религия. Подобные классы я называю "монолитами" и считаю их очень вредными. Со временем они превращаются в настоящих "монстров".
Как раз вот сейчас и занимаюсь на работе раскалыванием очередного "монолита" на кусочки.

AN>>- где происходит переход от типов к "инстансу"?
Q>Я не могу за вас весь код написать, подумайте сами это ведь элементарно.
меня не код интересует а "концепт". Если я задаю типы для регистрации и типы для Show, то конкретная имлпементация должна происходить внутри по внутренним Map-ам, причем исключительно 1:1.
"он же будет создавать призентер вложенного окна, как этот презентер вложенного окна соединяется с объектом окна, смотри код выше." как это состыковать с этим совем непонятно.
Поэтому и был следующий вопрос
AN>>- Если у меня несколько документов с одним въювом и презентером — какой из них показывать?