[Conception]application swing avec SGBD

Bonjour tout le monde :D

Je m'interroge sur la meilleure manière de concevoir ET implémenter une application Java "standalone" utilisant Swing et un SGBD.

Voici grosso modo ma manière de faire :

• je crée une classe pour l'accés à la BD, cette classe est un singleton
• Je mets aussi la fenetre principale en singleton
• Je crée un médiateur (listener) pour la fenetre principale et les boites de dialogue
• le mediateur de la fenetre principale est aussi un singleton
• Chaque médiateur a la charge de récolter les info de l'IHM et crée un thread ,si besoin est , pour effectuer le traitement et mettre à jour l'IHM

Un des (nombreux ? ) problèmes de cette façon de procéder est que je me retrouve avec des singletons qui se référencent mutuellement. :aie:

Voilà, je voudrais avoir votre avis sur ma manière de faire et connaitre la votre.

J'espère que c'est clair.Dans tous les cas je suis à votre disposition pour de plus amples détails.

Merci beaucoup pour votre aide ;)

Salut,

Citation:

---

Envoyé par afrikha

Un des (nombreux ? ) problèmes de cette façon de procéder est que je me retrouve avec des singletons qui se référencent mutuellement. :aie:

---

Personnellement je prefère n'utiliser qu'une seule classe Singleton qui représente mon application. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class MonApplication {   private static final MonApplication INSTANCE = new MonApplication();   private MonApplication() { // do nothing }   public static MonApplication getInstance() { return MonApplication.INSTANCE; } }

---

Ce singleton comporte en plus toutes les autres instances "uniques" de l'application, mais ce ne sont pas forcément des singleton mais de simple champs. Par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

/** La frame principale de l'application (unique) */ private MainFrame mainFrame; /** Le DAO permettant d'accéder aux données via JDBC (unique) */ private DAO dao;   public MainFrame mainFrame() { return this.mainFrame; }   public DAO dao() { return this.dao; }

---

Le singleton comporte également une méthode private chargé d'initialiser tous les attributs de mon Singleton dans le bon ordre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

private void initialize(String[] args) { this.dao = new MyDAOImplementation(); this.mainFrame = new MainFrame(); // Affiche la frame : SwingUtilities.invokeLater(new Runnable() { public void run() { MonApplication.this.mainFrame.setVisible(true); } });   // etc... }

---

Je n'utilise pas le constructeur du Singleton pour cela car on peut se retrouver dans une erreur cyclique (par exemple le constructeur appelle new MainFrame() qui appelle getInstance() qui rappelle le constructeur car on n'est toujours pas retourné du précédent, etc.).

La méthode initialize() est private car elle ne doit être utilisé qu'un seule et unique fois au démarrage de l'application. C'est pourquoi mon main() se trouve dans la classe Singleton, et effectue généralement quelque chose du style :

Code:

---

1 2 3

public static void main(String[] args) { MonApplication.getInstance().initialize(args); }

---

Le plus dur étant de bien séparer les différentes couches, afin d'éviter d'avoir des références croisées lors de l'initialisation...


a++

J'arrive un peu tard après la bataille et je vois déja tout les corps enterrés et je n'ai rien de mieux à dire. Si il fait beau.

Citation:

---

Envoyé par sinok

J'arrive un peu tard après la bataille et je vois déja tout les corps enterrés et je n'ai rien de mieux à dire. Si il fait beau.

---

Ben non au contraire il n'y a pas de solution miracle !!!

a++

Merci adiGuba pour cette participation très enrichissante :ave:

Citation:

---

Envoyé par adiGuba

Le plus dur étant de bien séparer les différentes couches, afin d'éviter d'avoir des références croisées lors de l'initialisation...

---

Oui, c'est vrai que c'est la partie un peu "critique" : Par exemple comment faire pour le mediateur de la main frame ? la frame a besoin de connaitre le médiateur et le médiateur a besoin de connaitre la frame !, qui initialiser en premier ?

Merci encore une fois ;)

Pour ma part :

- aucun singleton (je ne vois absolument pas à quoi ils servent)

- un package d'accés bdd et de données bdd (en gros une classe par table)

- un package swing

- un package main, configuration, etc.

Le package bdd ne référencie jamais (ou presque) (ou par erreur) ce qu'il y a dans les autres.

Le package main peut connaître tout ce qu'il y a dans les autres.

Pour le package GUI, je crée, dans ce package, une interface d'accés (sorte de driver), que une classe du package main met en oeuvre, grâce à laquelle un objet GUI peut activer un service du package main. Le package GUI ne connait donc le package main que par cet intermédiaire.

Heu... c'est clair ??

Citation:

---

Envoyé par adiGuba

Ben non au contraire il n'y a pas de solution miracle !!!

a++

---

C'est sûr, mais bon celle que j'utilise se rapproche de ce que tu as expliqué, d'où mon post

Je n'ai pas trouvé de reponse à ma question :(

Citation:

---

Envoyé par afrikha

Par exemple comment faire pour le mediateur de la main frame ? la frame a besoin de connaitre le médiateur et le médiateur a besoin de connaitre la frame !, qui initialiser en premier ?

---

Je ne comprends pas ce problème de médiateur ?...

À ce que je comprends, pour toi, un médiateur c'est un truc qui gère les infos issues du GUI ; en gros un listener. Donc tu le crées avant (ou après) ; il n'a pas besoin de connaître ou d'avoir une référence vers la fenêtre, puisque cette référence lui est passée sur réception d'un événement. Lorsque le médiateur est une classe interne, il a une référence interne vers la classe engobante - donc la fenêtre - par défaut, mais c'est uniquement une facilité.

C'est comme la séquence très classique pour un bouton :

Code:

---

1 2 3 4

ActionListener listen = new EcouteDeMonBouton(); JButton bouton = new JButton(); bouton.addActionListener(listen);

---

On peut faire les créations dans n'importe quel sens.

Bonjour,
Ben justement non...Un médiateur est plus qu'un simple listener, c'est un design pattern.

il faudrait savoir ; dans ton message #1 tu nous dis : Je crée un médiateur (listener) pour la fenetre principale et les boites de dialogue ; dans ton message #10, lorsque j'admets l'idée que un listener serait un médiateur : Ben justement non... Un médiateur est plus qu'un simple listener. Dis nous tout de suite. On connait les liens et les différents modes de patterns.

De toutes façons cela ne change pas fondamentalement le problème, donc la solution ; par le système de ce que tu voudras qui correspond aux événements du listener, tu reçois une référence de l'objet GUI activé. Donc tu peux créer dans n'importe quel ordre gui et médiateur. Cette combine de passer la référence lors du déclenchement de l'action, et non pas lors de la construction du médiateur, est très pratique.

Si, en plus, le médiateur est une classe interne, alors c'est encore plus pratique mais, bien sûr, c'est plus difficile pour l'indépandance des niveaux de traitement...

A+.

Citation:

---

Envoyé par spekal

il faudrait savoir ; dans ton message #1 tu nous dis : Je crée un médiateur (listener) pour la fenetre principale et les boites de dialogue ; dans ton message #10, lorsque j'admets l'idée que un listener serait un médiateur : Ben justement non... Un médiateur est plus qu'un simple listener. Dis nous tout de suite. On connait les liens et les différents modes de patterns.

---

Bon ben désolé pour le malentendu alors.

Citation:

---

De toutes façons cela ne change pas fondamentalement le problème, donc la solution ; par le système de ce que tu voudras qui correspond aux événements du listener, tu reçois une référence de l'objet GUI activé. Donc tu peux créer dans n'importe quel ordre gui et médiateur. Cette combine de passer la référence lors du déclenchement de l'action, et non pas lors de la construction du médiateur, est très pratique.

---

Oui j'avais envisagé cette possibilité, mais j'hésite entre cette méthode ou bien crée dans la frame une méthode setMediateur et dans le Mediateur une méthode setFrame. Des avis ?

Citation:

---

Si, en plus, le médiateur est une classe interne, alors c'est encore plus pratique mais, bien sûr, c'est plus difficile pour l'indépandance des niveaux de traitement...

---

Ce n'est pas une solution envisageable car le mediateur est assez conséquent et donc ça nuirait à la lisibilité du code.

Merci pour votre aide ;)

Enfin pour ce qui du motif médiateur en java tu peux t'en passer si tu passes par une ActionMap et des classes héritant d'AbstractAction à la place des listeners(couplé à une InputMap tu obtiens une très bonne réactivité pour ton appli)
http://java.sun.com/docs/books/tutor...html#actionapi
http://java.sun.com/docs/books/tutor...html#actionmap

Merci sinok pour cette approche différente ;)
Je vais essayer de creuser un peu dans ce sens avec les liens que tu m'as donné.

à bientôt :D

Sinon tu as jMatter ;)

Je prends note, mais ça a l'air d'étre une usine à gaz.
Quelqu'un l'a-t-il déjà utilisé ? car j'aimerai bien avoir quelques retours avant de me plonger dans sa doc.

:merci:

Citation:

---

Envoyé par afrikha

Oui j'avais envisagé cette possibilité, mais j'hésite entre cette méthode ou bien crée dans la frame une méthode setMediateur et dans le Mediateur une méthode setFrame. Des avis ?

---

Je n'aime pas beaucoup les liens dans les deux sens, mais c'est quelque fois une façon de se sortir d'affaire.

Perso je fais souvent une construction du type suivant :

Dans le coté GUI :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

public class GUI extends javax.swing.J... { // une interface générique qui définit les méthodes nécessaires du médiateur public static interface Mediatisable { public void boum(GUI vue); }   // le constructeur, qui reçoit un Mediatisable public GUI(Mediatisable mediateur) { leMediateur = mediateur; }   private Mediatisable leMediateur;   ... etc ... }

---

Dans une classe Main, ou n'importe où, l'implémentation du Mediatisable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class SuperGenialMediateur implements GUI.Mediatisable { public void boum(GUI vue) { ... BOUM ! BOUM ! } }   public void uneMethodeQuelquePart() { SuperGenialMediateur genial;   genial = new SuperGenialMediateur(); GUI gui = new GUI(genial); }

---

... de cette façon, les liens réciproques me semblent un peu mieux protégés. Ce montage facilite énormément les tests, par exemple.

A+.

Bonjour spekal et merci de ta reponse ;)

Si j'ai bien compris le médiateur ne connait pas la vue à sa construction mais quand il reçoit un événement (event), c'est ça ?

sinon :

Citation:

---

Envoyé par spekal

Je n'aime pas beaucoup les liens dans les deux sens, mais c'est quelque fois une façon de se sortir d'affaire.

---

La question que je me pose est : Quand employer ces fameux liens dans les deux sens ?


:merci:

Citation:

---

Envoyé par afrikha

Si j'ai bien compris le médiateur ne connait pas la vue à sa construction mais quand il reçoit un événement (event), c'est ça ?

---

C'est en tous cas ce que je propose.

Citation:

---

Envoyé par afrikha

La question que je me pose est : Quand employer ces fameux liens dans les deux sens ?

---

En théorie : jamais. En pratique : quand t'arrives pas à trouver une archi objet qui te satisfait :D

Après une longue réflection, j'ai décidé d'opter pour la technique d'adiGuba. C'est celle qi m'a parue la plus claire et la plus simple à mettre en oeuvre.
Toute fois ce n'est que mon avis personnel, et ça ne veut en aucun cas dire que la façon de spekal est mauvaise. C'est juste une question de goût ;)