Гранулярность MVP и презентатора

Мы используем шаблон MVP и Winforms с большим успехом. Однако всегда возникает вопрос о MVP:

Что такое хорошая гранулярность для докладчиков?

Я имею в виду: С Winforms тонкая гранулярность обычно хорошо работает для пользовательских элементов управления. Таким образом, легко использовать пользовательские элементы управления и использовать их в качестве строительных блоков при разработке более сложных графических интерфейсов. Однако наличие такой же (тонкой) гранулярности с докладчиками представляется проблемой.

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

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

Обратите внимание, что в обоих случаях возможен 1-презентатор-1-просмотр. Что считается изменением "1-view".

Что обычно считается лучшим методом для гранулярности презентатора с использованием MVP и Winforms?

Мелкозернистые презентаторы и настраиваемое поведение через параметры или что-то в этом роде?
Крупнозернистые презентаторы и повторное использование нижнего презентатора?
Что-то еще?

Отказ от ответственности: в основном мы используем Контроллер Supervising, но я думаю, что это также относится к Пассивному представлению. Извините за длинный вопрос.

Ответ 1

Мы используем MVP для всех наших клиентов, и это определенно разговор, который возникает не один раз. Насколько чистым должен быть наш код за классами и докладчиками? Сказав это, мы решили использовать подход крупнозернистого презентатора. В принципе, каждая форма будет иметь свой собственный презентатор и будет только получать и устанавливать свойства любого элемента управления в конкретной форме, используя его представление. Наведение элементов управления - вызов db для заполнения combobox, например, - находится в классе публичной службы. Любая проверка введенных пользователем данных находится в классе BO, который может быть повторно использован любым и/или всеми ведущими. Надеюсь, это поможет.

Ответ 2

В моей системе CAD-CAM мои ведущие не используют пользовательские элементы управления. Элементы управления пользователя находятся в представлении, которое находится в сборке EXE, которые реализуют представление, взаимодействующее с презентатором.

Если вы хотите отобразить список клиентов, я передаю его в представление, которое имеет DisplayCustomerList, и использует любую комбинацию пользовательских элементов управления, чтобы отобразить список клиентов. Если несколько просмотров показывают список клиентов одинаково, то в сборке ExE/View они используют пользовательский элемент управления или класс для этого. Этот класс не выходит за пределы этой сборки.

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

Иерархия выглядит так:

Просмотр EXE Реализация презентатора Command Assembly - команды выполняются ведущим, который модифицирует модель Интерфейсы презентатора Модельные сборки

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

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

Существенный вопрос, который я задаю при использовании MVP, - "Что произойдет, если вы хотите полностью заменить формы чем-то другим?". Ответы на этот вопрос будут определять, где вы слишком зависите от конкретного пользовательского элемента управления или механизма формы.

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