MVP и UserControls и вызов

Question

Я получаю удовольствие, пытаясь разобраться с некоторыми вещами MVP, поскольку они относятся к пользовательским элементам управления. Я использую .NET WinForms (или что-то близкое к нему) и шаблон Supervising Controller (ну, я думаю, что я :).

Пользовательский элемент управления является частью MVP-приложения (его представление и связанный с ним Presenter и т. д.). Сначала всегда запускается Presenter, и он запускает модель (-ы), а затем вид (-ы). Представление строит свой пользовательский интерфейс, частью которого будет НОВЫЙ UC, то есть представление.

Теперь (форма) Presenter должен знать о Presenter UC, но я думаю, что он ничего не знает о том, как составляется представление. Например, Presenter не знает, что UC является частью коллекции Controls формы, и не должен.

Кроме того, опыт проектирования не должен быть изменен; IOW разработчик представления (формы) должен иметь возможность выбрать пользовательский элемент управления из панели инструментов и поместить его в форму.

Итак, к моим вопросам. Во-первых, верны ли мои предположения выше? Несколько ошибочно? Перепутали? WTF ты думаешь?

Во-вторых, правильно (достаточно?), чтобы форма View вызывала UC View, а Presenter формы вызывала Presenter UC и имела какой-то механизм, позволяющий сообщать UC View, каков его Presenter? Это ломает мой "Ведущий первым" правило, но я не уверен, как еще это сделать.

Любые другие мысли, предложения, комментарии с радостью принимаются.

- nwahmaet

Answer 1

Докладчик должен рассматриваться как «автономное состояние» в уровне представления. Это означает, что он отвечает за то, чтобы представление представления состояния модели было синхронизировано. Причина, по которой я об этом говорю, заключается в том, что «шаблон» MVP часто теряется в догматическом представлении как вещи должны быть отделены. Похоже, что это одна из причин, по которой Мартин Фаулер решил уточнить терминологию вокруг шаблона MVP .

Мой любимый вариант MVP - пассивное представление , поэтому мой ответ основан на этом .

Я очень часто реализую составные пользовательские элементы управления и формы, используя шаблон пассивного представления. По сути, есть 3 разные конфигурации:

<Ол>

Один докладчик для всех пользовательских элементов управления в иерархии. Свести вид с помощью интерфейса.

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

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

Хотя это решение последней инстанции для меня (из-за его сложности), я думаю, что последний вариант - это решение, которое вы ищете.

Answer 2

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

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

Я пришел к выводу, что ВСЕ пользовательские элементы управления зависят от реализации представления и поэтому должны полностью содержаться в хранилище представлений большего шаблона. Таким образом, у них нет собственных презентаторов ... По крайней мере, они не связаны с самой реализацией элемента управления. Вместо этого они должны управляться косвенно презентатором родительского окна через сквозные поля, отображаемые в интерфейсе представления. Короче говоря, пользовательский элемент управления предоставляется презентатору не через его собственный интерфейс, а через общий сквозной интерфейс, реализованный его родительским представлением. Назовите это «интерфейсом частичного представления».

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

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

Answer 3

Ваши вопросы являются общими, и могут применяться различные схемы.

В этом случае я предполагаю, что вы должны взглянуть на шаблон наблюдателя.

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

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

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