Применение шаблона MVP к JDialogs - PullRequest
Новая
       13

Применение шаблона MVP к JDialogs

3 голосов
/ 06 февраля 2009

Я пишу Swing-приложение, и далее мой предыдущий вопрос остановился на использовании шаблона Model-View-Presenter для отделения пользовательского интерфейса от бизнес-логики. .

Когда мое приложение запускается, оно выполняет следующий код: 

Model model = new BasicModel();
Presenter presenter = new Presenter(model);
View view = new SwingView(presenter);
presenter.setView(view);

presenter.init();

, который создает пользовательский интерфейс. События генерируются View и делегируются Presenter. Presenter затем манипулирует Model и обновляет View соответственно.

Чтобы обработать некоторые события, мне нужно получить дополнительную информацию от пользователя. Я полагаю, что в случае этих событий целесообразно, чтобы представление Swing создавало новое окно JDialog.

Одна мысль заставляет меня думать, что это может быть подходящим кодом в оригинале Presenter: 

public void handlePreferences() {
    Preferences prefs = view.getPreferences();
    model.setPreferences(prefs);
}

То есть содержимое каждого JDialog должно представлять отдельный объект, который должен быть извлечен из View и обновлен в Model. Однако это оставляет вопрос: создать ли я Model для представления объекта Preferences и новый Presenter для обработки событий в этом JDialog?

Мне кажется, что создание новых Presenter и Model, внутренних по отношению к исходному View, заставляет меня выполнять большую работу, которую было бы труднее перенести, если бы я захотел изменить пользовательский интерфейс для использования JSF например.

Пожалуйста, не стесняйтесь добавлять комментарии для уточнения.

Ответы [ 3 ]

8 голосов
/ 13 февраля 2009

Хотя «вложенные» шаблоны проектирования весьма распространены, в вашем случае это не обязательно. Опираясь на другие ответы:

Модель
- Содержит все реальные данные, переменные, объекты
- знает, как установить для сохраненных значений данных новые значения
- отвечает на заказы (вызовы методов)
- имеет метод setPreferences (значение1, значение2, значение3 ...);

View
- это IO для приложения, просто вывод и ввод
- он может работать только на себя, на свое состояние
- поддерживает локальные переменные и объекты, например. у него есть JButtons, JMenus, int counter ...
- он знает, как сообщить предъявителю изменения состояния
- его состояние видимо докладчику или раскрывается при вызове метода
- отвечает на заказы (вызовы методов)
- знает, как получить настройки от пользователя
- имеет метод askForPrefs ();
- имеет метод getPrefState ();

Presenter
- реагирует на изменения состояния
- принимает все решения, говорит другим объектам, что делать (а не как)
- знает, когда нужны настройки
- знает, где взять новые настройки и где их поставить
- имеет метод newPrefsAvailable ();

... для получения дополнительной информации от пользователя. Я полагаю, что в случае этих событий целесообразно, чтобы представление Swing создавало новое окно JDialog.

Presenter - проверяет модель, определяет новые предпочтения
Ведущий - this.myView.askForPrefs (); // сообщает представлению запросить у пользователя значения pref
View.askForPrefs - открывает окно JDialog, ретвалы сохраняются в виде как изменение состояния
View - this.myPresenter.newPrefsAvailable ();
Presenter - отвечает this.myModel.setPreferences (this.myView.getPrefState ());
Model.setPreferences - изменяет сохраненные значения на View.getPrefState ()
Ведущий - проверяет модель - определяет хорошие предпочтения
Ведущий - продолжает

JDialog рассматривается как просто расширение представления, оно является членом представления, как и JButton. Модель имеет официальные фактические значения предпочтений, а представление имеет локальные переменные, которые представляют состояние JDialog.

1 голос
/ 11 февраля 2009

Нет, вам не нужна другая "модель" только для предпочтений

Просто передайте ведущий и режим в качестве аргументов в конструкторе JDialog. Программировать большое приложение Swing легче, когда есть

  • 1 модель
  • 1 контроллер (который сам может содержать меньшие)
  • несколько представлений (но на ЖЕ классах данных / моделей)

Обратите внимание, что 1 модель! = 1 класс. «Модель» Swing-приложения может фактически быть «деревом» отдельных «модельных» классов которые имеют общий «корень».

Так что в вашем случае вам нужно

Модель «Global» -> (содержит) модель «Предпочтения».

1 голос
/ 06 февраля 2009

Мой совет - подумать о том, каковы эти «предпочтения». Являются ли они частью базовой бизнес-логики? Если так, то они должны быть частью структуры модели. Определяют ли они предпочтительный способ взаимодействия пользователя с бизнес-данными? Тогда они должны быть частью зрения. Это может показаться теоретическим, но, по моему опыту, в конечном итоге это избавляет от многих головных болей.

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

...