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

Question

Я пишу приложение Swing, а затем до my previous question, установили с использованием шаблона 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.

Одна линии мышления заставляет меня чувствовать это может быть соответствующим кодом в Orignal Presenter:

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

Нет, не нужна еще одна «модель» только для Preferences

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

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

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

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

модель "Global" -> (содержит) модель "Preferences".