MVP с одним окошком проблем не вызывает.
А вот с двумя никак не придумаю, как лучше.
Проблема в том, что для вставки документа нужно иметь "указатель" на документ.
А ни интерфейсу вьюва ни презентеру "не положено знать" об используемой технологии GUI. Ну типа того — сегодня винформс, завтра впф.
Пока приходится всё в форме делать.
...
Хотя пожалуй, только что придумал, что скажете?
Главная форма говорит своему презентеру "создай новое окошко".
Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.
Здравствуйте, AlexNek, Вы писали:
AN>MVP с одним окошком проблем не вызывает. AN>А вот с двумя никак не придумаю, как лучше. AN>Проблема в том, что для вставки документа нужно иметь "указатель" на документ. AN>А ни интерфейсу вьюва ни презентеру "не положено знать" об используемой технологии GUI. Ну типа того — сегодня винформс, завтра впф.
Значит нужен кто-то третий, кто все это будет знать.
AN>Пока приходится всё в форме делать. AN>... AN>Хотя пожалуй, только что придумал, что скажете?
AN>Главная форма говорит своему презентеру "создай новое окошко". AN>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.
Если все просто, то вполне подходящее решение. Я вообще в mvp и mvvm использую такой подход: есть служебный класс который занимается создание форм и связыванием со все остальным, его можно так же связать с ioc-контейнером. Вот примерный код:
public static class WindowService
{
//регистрируем тип формы и презентера. Вызывается в начале метода Main для каждого класса формыpublic static void Register<TView,TPresenter>()
{
}
// отображает форму и возвращает ее объект.public statiс TView Show<TPresenter,TView>(){}
}
public class PresenterBase
{
private IView _view;
private Model _model;
public PresenterBase()
{
_view= WindowService.Show<PresenterBase,IView>();
_model=new Model();
}
}
Просто, минимум когда, можно допелить под любые потребности.
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, AlexNek, Вы писали:
AN>>MVP с одним окошком проблем не вызывает. AN>>А вот с двумя никак не придумаю, как лучше. AN>>Проблема в том, что для вставки документа нужно иметь "указатель" на документ. AN>>А ни интерфейсу вьюва ни презентеру "не положено знать" об используемой технологии GUI. Ну типа того — сегодня винформс, завтра впф.
Q>Значит нужен кто-то третий, кто все это будет знать.
Можно и третий, но проблемы остаются: будет ли команда создания окна приходить в презентер или этот третий будет всё делать сам. Или этот третий будет просто обрабатывать команду.
Что может знать этот "третий"?
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> }
[#яяяя]
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>Просто, минимум кода, можно допилить под любые потребности.
Вообще то тут у меня вопросов больше чем ответов.
— Какого WindowService знает и "M" и "V" и "P" и "GUI"?
— отчего каждый презентер создает модель?
— где происходит переход от типов к "инстансу"?
— Если у меня несколько документов с одним въювом и презентером — какой из них показывать?
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, Qulac, Вы писали:
Q>>Здравствуйте, AlexNek, Вы писали:
AN>>>MVP с одним окошком проблем не вызывает. AN>>>А вот с двумя никак не придумаю, как лучше. AN>>>Проблема в том, что для вставки документа нужно иметь "указатель" на документ. AN>>>А ни интерфейсу вьюва ни презентеру "не положено знать" об используемой технологии GUI. Ну типа того — сегодня винформс, завтра впф.
Q>>Значит нужен кто-то третий, кто все это будет знать. AN>Можно и третий, но проблемы остаются: будет ли команда создания окна приходить в презентер или этот третий будет всё делать сам. Или этот третий будет просто обрабатывать команду. AN>Что может знать этот "третий"?
В моем случае команда будет приходить в презентер главного окна, он же будет создавать призентер вложенного окна, как этот презентер вложенного окна соединяется с объектом окна, смотри код выше.
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"?
А почему ему этого не знать, что запрещает?
AN>- отчего каждый презентер создает модель?
Может и не создавать, это может делать WindowService,а для простых диалоговых окон можно обойтись и без модели.
AN>- где происходит переход от типов к "инстансу"?
Я не могу за вас весь код написать, подумайте сами это ведь элементарно.
AN>- Если у меня несколько документов с одним въювом и презентером — какой из них показывать? AN>Может лучше mvcsharp пользовать тогда?
Ни чего не могу сказать, этим не пользовался.
Здравствуйте, 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>>- Если у меня несколько документов с одним въювом и презентером — какой из них показывать?
AN>>>- где происходит переход от типов к "инстансу"? Q>>Я не могу за вас весь код написать, подумайте сами это ведь элементарно. AN>меня не код интересует а "концепт".
Так концепт в том и заключается, что если мы хотим создавать вид из презентера, а призентер не должнен знать тип вида, то презентер должен эту работу поручать специальному объекту и все. Я же там написал, что "допилить напильником".
Здравствуйте, AlexNek, Вы писали:
AN>Главная форма говорит своему презентеру "создай новое окошко". AN>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.
Почему бы просто не запускать новый экземпляр приложения под новый документ со всеми вытекающими?
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, AlexNek, Вы писали:
AN>>Главная форма говорит своему презентеру "создай новое окошко". AN>>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка. K>Почему бы просто не запускать новый экземпляр приложения под новый документ со всеми вытекающими?
Это что типа шутки? Иначе совсем непонятно.
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, Kernan, Вы писали:
K>>Здравствуйте, AlexNek, Вы писали:
AN>>>Главная форма говорит своему презентеру "создай новое окошко". AN>>>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка. K>>Почему бы просто не запускать новый экземпляр приложения под новый документ со всеми вытекающими? AN>Это что типа шутки? Иначе совсем непонятно.
От блинский ёж. Я что-то о чём-то своём подумал . Забей, в общем
Здравствуйте, AlexNek, Вы писали: AN>Главная форма говорит своему презентеру "создай новое окошко". AN>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.
Здесь ошибка. Команда/Екшен говорит создай новое окошко, она как раз и знает где она находится, какие получить параметры, что создать и что вернуть
Здравствуйте, stenkil, Вы писали:
S>Здравствуйте, AlexNek, Вы писали: AN>>Главная форма говорит своему презентеру "создай новое окошко". AN>>Презентер "говорит" интерфейсу вьюва "создай новое окошко", а в ответ получает презентер нового окошка.
S>Здесь ошибка.
Где именно и почему? S>Команда/Екшен говорит создай новое окошко, она как раз и знает где она находится, какие получить параметры, что создать и что вернуть
Окошко получает команду, команда посылается презентеру, презентер решает какую послать команду въюву, въюв исполняет команду — это вроде нормальный MVP.
Теперь ваш вариант:
Окошко получает команду, окошко исполняет команду — стандартная схема "вермишели".
Или я что то не так понял?
