MVP и гранулярность докладчика

Question

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

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

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

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

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

Обратите внимание, что в обоих случаях 1-Presenter-1-View достижим. Изменения, которые считаются «1 взглядом».

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

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

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

Answer 1

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

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

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

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

Просмотр EXE Внедрение Presenter Сборка команд - команды выполняются ведущим, который модифицирует модель Интерфейсы докладчика Модельные сборки

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

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

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

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

Answer 2

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