Discussion :

[hegros]

Oui d'accord hegros, merci.

Je suppose que tu voulais dire controlleurIHM3 au lieu de controlleurIHM2,
et controlleurIHM4 au lieu de controlleurIHM3 ?

non du tout En fait c'est un découpage pour organiser la logique applicative cela doit venir à cause des chiffres cette confusion, voilà un diagramme avec des noms plus parlant je l'espère.

la granularité est à ajuster, là je n'ai que quelques classes dans le diagramme, dans la réalité il y en a des centaines voir des milliers. Aussi l'interet c'est de gagner en cohésion dans les classes logicielles et de diminuer le couplage.

l'interet est de faire avec un court exemple en exposant le plus la chose.

on peut aussi en rester à une définition du pattern controleur : il permet de résoudre le problème de à qui transmettre un message venant d'une IHM cependant dans la réalité on utilise des objets DAO qui sont des controleurs...


On peut dans l'absolu ignorer le controleur dao on voit nettement apparaitre 2 controleurs de métiers différents dans une application cela n'est pas rare. Avec 1 seul controleur pour toutes les IHM et objets métiers il perdrait rapidemment sa cohésion et augmenterait considérablement son couplage avec tout ce qui s'en suit qu'on connait par coeur plus de maintenance et moins de réutilisabilité.

Qu'est-ce que vous en dites les amis ?

[rp37000]

Merci hegros,

Impeccable , nickel c'est beaucoup plus clair pour moi là .

Grâce à toi je découvre la notion de DAO, t je trouve ça très très intéressant:
- http://java.sun.com/blueprints/corej...essObject.html
-Petit Diagramme de séquence (le tien en fait ) :
http://www.developpez.net/forums/d63...onne-pratique/

En fait concernant cette problématique d'accés aux données, ça fait longtemps que je cherchais à "inventer" qqch d'aussi souple que ça, mais seul dans mon coin j'y arrivais pas , je n'étais pas satisfait du résultat.
Ben, vive le Pattern DAO, et pour fêter ça j'ai ouvert une nouvelle
discussion sur justement le Contrôleur DAO, et plus précisément le Transfer Object et son couplage:
http://www.developpez.net/forums/d66...t/#post3903706


Bonne année à tous et toutes, et merci encore!!
En particulier à Tristan_m, hegros et Patriarch24.

[Patriarch24]

J'ai une série de liens sur les patterns de présentation (MVC, MVP, etc), j'espère donner d'ici peu (avec moi, "peu" peut signifier la fin du mois) un article pour le site (les liens sont en anglais, je fais faire un travail de traduction et de synthèse). Bien entendu, je compte sur vous pour me relire et critiquer !

[rp37000]

Ok super Patriarch24;

Merci et bon courage .

[alatox]

Bonjour,

Pour commencer, une petit question. Le contrôleur IHM est-il un contrôleur qui contient tous les autres contrôleurs ?

Je m'explique, imaginons une application (Swing comme par hasard) avec un menu d'administration qui doit permettre d'accéder aux tables d'une base de données et de les gérer. Les modèles sont donc des Listes de beans que l'on contrôle.

Pour un modèle liste, je considère que la vue est composé du tableau qui permet de voir l'état de la table, de la fenêtre qui s'ouvre lorsque l'on appuie sur ajouter ou modifier une ligne. Lorsque j'appuie sur ajouter, le controleur se charge de rendre visible la vue d'ajout. Je saisis des informations dans cette vue. Après un appuie sur valider dans la fenêtre de création par exemple. Le contrôleur demande au modèle de liste de changer, ce dernier notifie la vue, blabla ...

Maintenant si dans la fenêtre d'insertion j'ai à gérer des listes (des nouveaux modèles) qui remplissent une combo box. J'ai donc un controleue pour cette liste et la vue est une combo box.


Voici mes questions : j'ai besoin de la vue combo box pour construire la vue d'un modèle Liste. Ce faisant j'ai deux controleurs à déclarer.

Est ce que le premier contrôleur doit instancier le second contoleur (celui de la combo box) puis utiliser une méthode de type getVue() pour passer la vue combox box à la vue Liste. Si tel est le cas il est impossible pour le controleur Liste (qui aurait été chargé de faire un new VueListe(modeleListe)) de faire faire le new VueListe(modeleListe) sans avoir à instancier un "controleur combo box", et l'on doit rajouter des méthodes pour transmettre des composant à la vue Liste.

Vous voyez mon problème ? la statégie proposée parait-t-elle viable ? Existe-t-il une solution ?


Merci pour vos réponses.

[rp37000]

Alors là aucune idée !
Désolé!