MVP и несколько пользовательских элементов управления

Я пытаюсь использовать шаблон MVP, а Im работает с проблемой дизайна. Im разрабатывает приложение, которое будет иметь несколько UserControls. Сам пользователь UserControls не имеет ничего общего друг с другом и только представляет собой подмножество фактической модели. Из того, что я читал, люди склонны говорить, что вы должны использовать один докладчик за просмотр. Кажется, это имеет смысл, но если у меня есть 30 UserControls, мне действительно нужно 30 презентаторов? С другой стороны, если у меня есть 1 Presenter и 1 View, которые представляют весь вид приложения, тогда у Ill есть раздутые интерфейсы View и Presenter. Затем каждый вид должен будет реализовывать методы, которые не имеют к этому никакого отношения. Мой вопрос в том, есть ли лучший способ обработки нескольких UserControls или я должен просто создать 1 Presenter для каждого представления?

Ответ 1

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

Теперь у вас может быть один класс Менеджера Presenter, возможно, который может предоставить вам доступ к каждому интерфейсу презентатора, как Принцип Разделения Интерфейса, утверждает либо наследование (есть глобальный конкретный докладчик, который реализует множество интерфейсов презентатора, которые нарушают единую ответственность) или агрегацию (с отдельными докладчиками для каждого интерфейса и получения функций... таким образом, глобальный интерфейс будет функциями get) или сочетание обоих (глобальный презентатор, являющийся в некоторой степени адаптером).

Я думаю, что лучшее решение, хотя должно было состоять только в 30 разных докладчиках.

Ответ 2

Вы должны делать один ведущий на один элемент управления из-за:

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

Обычно упоминаются две проблемы, связанные с решением "ведущий на управление":

Общий контекст - проблема, из-за того, что из-за того, что все элементы управления просто показывают разные части одного и того же контекста данных страницы, эта ситуация может выглядеть как проблемный случай использования, приводящий к большому количеству извлечение избыточного кода данных в каждом элементе управления. Это легко разрешимо посредством инъекции зависимостей, когда страница (или контроллер) выполняет однократное извлечение данных, а затем вводит объект контекста данных в каждый из представлений \views (обычно реализующий некоторый интерфейс, позволяющий это). В случае шаблона MV-VM (Silverlight, WPF) такой же эффект может быть достигнут посредством ограничения данных, когда страница будет устанавливать свой DataContext, который затем будет использоваться из самих представлений
Связь между представлениями на одной странице - вторая проблема, которая легко разрешима с использованием нескольких подходов:
Элементы управления публикуют события, на которые подписывается страница, а затем делает прямые вызовы соответствующим методам в других элементах управления (страница является контейнером для всех элементов управления, что означает, что она знает обо всех своих членах).
Схема наблюдения
Шаблон агрегатора событий

В каждом из этих подходов элементы управления обмениваются данными друг с другом, не осознавая друг друга

Ответ 3

Каждый вид не должен реализовывать один и тот же интерфейс... Почему бы не определить интерфейсы для каждого элемента управления и иметь один презентатор для всего экрана, который содержит все элементы управления? Презентатор может "подключать" события к каждому представлению в соответствии с определенными событиями, определенными интерфейсом, для каждого представления, для соответствующих обработчиков событий в Presenter (и на контроллере, если вы выполняете MVPC). Вам также может понадобиться другой интерфейс для представления функций Presenter, доступный для общего доступа к просмотру ALL...

Если вы выполняете MVPC, то просматривайте события, которые влияют на Model wopuld, "обрабатываются" в контроллере, тогда как просмотр событий, которые влияют только на другие части представления, будут обрабатываться в презентаторе.

Ответ 4

Старый вопрос, но я собираюсь разобраться и не согласиться с другими ответами: вам не нужен один ведущий в UserControl, больше, чем вы хотите unit test на каждом UserControl - это будет слепое неправильное использование шаблона проектирования.

Пользователь UserControl не является видом.

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