Проблема проектирования: модель MVC с приложением Java CardLayout - PullRequest
Новая
       34

Проблема проектирования: модель MVC с приложением Java CardLayout

1 голос
/ 25 июля 2011

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

JFrame с JPanel («MainPanel»), добавленным в качестве компонента, а MainPanel имеет структуру CardLayout. MainPanel затем имеет несколько JPanel, которые пролистываются с помощью кнопок, Jcombo Box и выбора списка.

Я хочу реализовать модель MVC, используя эту структуру, и мне трудно найти способ сделать это. Пока у меня есть весь мой actionListener внутри, где я создал компоненты GUI и хочу отделить это и иметь контроллер для каждой JPanel, добавленной к MainPanel. Какими способами я мог бы разработать эту программу таким образом, чтобы я мог отделить свою логику действий и доступ к данным, и при этом поддерживать структуру CardLayout?

1 Ответ

2 голосов
/ 25 июля 2011

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

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

...