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

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

UserControl не является представлением.

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

Answer 4

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

• Если вы выполняете MVPC, тогда события, которые влияют на модель, будут «обработаны» в контроллере, тогда как события представления, которые влияют только на другие части представления, будут обрабатываться в Presenter.