MVP и UserControls и вызов

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

Пользовательский элемент управления сам по себе является частью приложения MVP (его вид и связанный с ним Presenter и т.д.). Ведущий всегда запускается первым, и он запускает Model (ы), а затем View (s). View создает свой пользовательский интерфейс, частью которого будет NEW UC, который является View.

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

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

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

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

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

- nwahmaet

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

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

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