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 разные конфигурации:

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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