Правильная конструкция модель-вид-контроллер

Question

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

У меня есть класс с именем MainView , который расширяет JFrame . У меня есть различные другие классы, которые помогают составить MainView , каждый из которых расширяет JPanel . В качестве примера один из этих классов называется ParameterView . Должен ли я позволить контроллеру видеть каждый из этих «подвидов» или я должен разрешить контроллеру видеть только MainView и через него все можно управлять?

Аналогично с моделью, должна ли модель управляться через один всеобъемлющий класс?

Спасибо!

Answer 1

В контексте приложения с графическим интерфейсом (Swing-like) Model-View-Controller является более расплывчатым предложением, чем конкретный проект. Количество вариантов этого «паттерна» ошеломляет, и нет ни одного «правильного» варианта, на который вы должны стремиться. Вы можете выбрать любой вариант, который соответствует вашим текущим потребностям (и не стесняйтесь изменять его по мере развития вашего приложения).

Тем не менее, вот несколько советов относительно ситуации, которую вы описываете

• Вы можете использовать механизм публикации / подписки (AKA: шаблон наблюдателя) или шаблон цепочки ответственности для отделения модели (или ее частей) от различных частей представления.
• Класс фасада (MainView), который упаковывает все части представления, кажется, является рецептом для «класса бога»: класса, который необходимо изменить практически при любом изменении в приложении (анти-шаблон). Выявив различные части представлений, вы сможете легче использовать их в новых контекстах.
• Наконец, реализация модели путем создания подклассов компонентов Swing не кажется хорошей идеей. Такой дизайн очень сложно проверить, а это значит, что он также очень жесткий. Предпочитаю делегирование наследованию. Или, как сказал JBrains: «Прекратите создавать подклассы, или котенок получит это». Используйте наследование только для переопределения методов Swing. Немедленно делегируйте всю логику объектам, которые полностью изолированы от Swing. Это будет способствовать тестируемости и будущей гибкости.

Answer 2

Мы получили очень хорошие результаты, используя концепцию Fowler Presentation Model . Я настоятельно рекомендую всем, кто занимается разработкой пользовательского интерфейса, прочитать обзор Фаулера ( GUI Architectures ) о различных подходах, которые были опробованы на этой арене, - это фантастическое прочтение и дает глубокое понимание проблем и успехов. каждого подхода.

Answer 3

MVC - это, как правило, Observer (модель наблюдаема), Strategy (различные стратегии вставляются в контроллер для обработки разных представлений) и Composite (представление представляет собой совокупность компонентов GUI).

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

Взгляните на tikeSwing . Это простая структура MVC для приложений Swing, как объяснено здесь .

Answer 4

Игнорируя MVC на мгновение, добавляйте специфичный для Swing код только в те компоненты представления, которые вы создаете, расширяющие JComponent. Передайте все остальное классу, который вы можете скомпилировать без Swing. Используйте интерфейсы, чтобы помочь вам в этом. Ваш контроллер должен иметь возможность обрабатывать запросы, не зная, что они пришли из события Swing. Ваша Модель должна иметь возможность обновлять состояние системы без обращения к классу Swing * Model. Ваше представление должно быть в состоянии описать, как представить результаты пользователю без ссылки на класс JComponent. После того, как вы это заработаете, вы можете легко создавать объекты JComponent, которые делегируются вашей модели, представлению и контроллеру.

Надеюсь, это поможет вам.

Answer 5

Хорошей идеей будет иметь минимальную связь между слоями, поэтому я, вероятно, позволю контроллеру видеть только MainView. Вам также следует рассмотреть возможность определения интерфейса, который реализует MainView, чтобы сделать структуру MVC более понятной. Контроллеру не нужно знать, что он имеет дело с JFrame.