Appliquer le modèle MVP à JDialogs

Question

Je suis en train d'écrire une application Swing, et en plus de my previous question, j'ai décidé d'utiliser le modèle Model-View-Presenter pour séparer l'interface utilisateur de la logique métier.

Lorsque mon application démarre, il exécute le code suivant:

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

presenter.init(); 

qui crée l'interface utilisateur. Les événements sont générés par le View et délégués au Presenter. Le Presenter manipule ensuite le Model et met à jour le View en conséquence.

Afin de gérer certains événements, j'ai besoin d'obtenir plus d'informations de l'utilisateur. Dans le cas de ces événements, je crois qu'il est approprié pour la vue Swing de générer une nouvelle fenêtre JDialog.

Une ligne de pensée me fait sentir que cela pourrait être le code approprié dans le Orignal Presenter:

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

C'est, le contenu de chaque JDialog devraient représenter un objet distinct qui doit être récupéré à partir du View et mis à jour dans le Model. Cependant, cela laisse la question: est-ce que je crée un nouveau Model pour représenter l'objet Preferences et un nouveau Presenter pour la gestion des événements dans ce JDialog?

Il me semble que la création d'une nouvelle Presenter et Model interne aux forces View originales me faire beaucoup de travail qui serait plus difficile au port si je voulais changer l'interface utilisateur d'utiliser JSF, par exemple.

N'hésitez pas à ajouter des commentaires pour clarification.

Answer 1

Bien qu'il ne soit pas rare d'avoir des motifs de conception "imbriqués", cela n'est pas nécessaire dans votre cas. Dessin sur les autres réponses:

Modèle
  - Contient toutes les données réelles, variables, objets
  - sait comment définir ses valeurs de données stockées sur les nouvelles valeurs
  - répond aux commandes (appels de méthode)
  - a la méthode setPreferences (value1, value2, value3 ...);

Voir
  - est le IO pour l'application, juste sortie et l'entrée
  - il ne peut fonctionner que sur son auto, son état
  - il maintient les variables locales et des objets, par exemple . il a JButton, JMenus, compteurs int ...
  - il sait comment informer le présentateur de changement d'état
  - son état est visible au présentateur, ou révélé par la méthode appel
  - répond aux commandes (appels de méthode)
  - sait comment obtenir les préférences de l'utilisateur
  - has méthode askForPrefs();
  - a la méthode getPrefState();

Présentateur
  - répond aux changements d'état
  - fait tout le décider, il dit aux autres objets ce qu'il faut faire (pas comment le faire)
  - sait quand les préférences sont nécessaires
  - sait où obtenir de nouvelles préférences et où les placer
  - A la méthode newPrefsAvailable();

... pour obtenir plus d'informations auprès de l'utilisateur. Dans le cas de ces événements, je crois qu'il est approprié pour la vue Swing de générer une nouvelle fenêtre JDialog.

Présentateur - vérifie le modèle, détermine de nouvelles préférences sont nécessaires
- Présentateur this.myView.askForPrefs(); // indique à l'utilisateur de demander à l'utilisateur des valeurs de préfixe
View.askForPrefs - affiche une boîte JDialog, retals stockés dans la vue en tant que changement d'état
View - this.myPresenter.newPrefsAvailable();
Presenter - répond avec this.myModel.setPreferences (this.myView.getPrefState());
Model.setPreferences - modifie les valeurs stockées à View.getPrefState()
Présentateur - vérifie le modèle - détermine les préférences sont bonnes
Présentateur - continue sur

Le JDialog est traité comme une simple extension de la vue , c'est un membre de la vue comme un JButton. Le modèle possède les valeurs de préférence réelles faisant autorité et la vue possède des variables locales qui représentent l'état du JDialog.

Answer 2

Mon conseil serait de penser à ce que ces «préférences» sont fondamentalement. Font-ils partie de la logique métier sous-jacente? Si oui, ils devraient faire partie du modèle structre. Spécifient-ils la manière préférée de l'utilisateur d'interagir avec les données de l'entreprise? Ensuite, ils devraient faire partie de la vue. Cela peut sembler théorique, mais d'après mon expérience, cela nous épargne beaucoup de maux de tête.

Si vous ne parvenez pas à résoudre ce problème, l'emplacement des préférences vous en donne un autre indice. Si elles doivent être sauvegardées avec les données manipulées, elles font probablement partie de la logique métier. Si elles sont enregistrées dans le fichier de préférences personnelles de l'utilisateur, elles ne le sont pas et doivent être considérées comme vue.

Answer 3

Non, vous n'avez pas besoin d'un autre « modèle » juste pour les Préférences

il suffit de passer le présentateur et le mode comme arguments dans le constructeur de la JDialog. Il est plus facile de programmer une grande application Swing quand il y a

• 1 modèle
• 1 contrôleur (qui lui-même peut contenir plus petits)
• plusieurs vues (mais sur les mêmes données/classes de modèle)

Notez que 1 modèle! = 1 classe. Le "modèle" d'une application Swing peut en fait être un "arbre" de classes "modèle" séparées qui ont une "racine" commune.

Donc, dans votre cas, vous devez

modèle "Global" -> (contient) modèle "Préférences".