Question a propos du pattern MVC

Version imprimable

07/12/2010, 15h48
Zoners

Question a propos du pattern MVC

Bonjour,

J'aurai une question a propos du Pattern MVC.

J'ai tres bien compris comment cela fonctionne, le modele gere les données, la vue s'occupe de l'affichage et le controleur va verifier que les données rentré dans la vue soit correct.Mais je me pose plusieurs question a propos des listeners et actionPerformed.

J'ai suivi plusieurs tutoriaux sur le systeme MVC sur plusieurs sites, et j'ai remarqué que le listener et/ou actionPerformed n'est pas forcement controler par le controleur.Je veus dire par la que dans certaines programmes que j'ai vu ces le controleur qui gere les listeners et l'actionPerformed et dans d'autre cas ces la vue qui cree le listener et gere les actionPerfomed.

Es-ce que les deux methodes sont correct? car le but du controleur est de verifier les données recupere de la vue(et verifier si elles sont corrects) et les integrers au modele, mais si j'ai bien compris rien ne l'oblige a forcement gerer les listeners et les actionPerformed.

Es-ce que les deux méthodes sont corrects?

Je me posais aussi une autre question, on dit que le controleur connait le modele et la vue, mais si j'ai bien compris ce n'est pas forcement le controleur qui cree la vue et le modele, ceux-ci(modele et vue) peut être envoyé au constructeur du controleur pour gerer les données, mais je ne suis pas sur que ca soit correct non plus donc j'aurai voulu un avis.

Si vous pouviez m'eclairer et me dire ce qui est correct de ce qui est faux ca m'aiderait beaucoup .

Merci d'avance.
07/12/2010, 17h50
merill

C'est un pattern, mais après chacun prend des libertés avec.

Un JButton a
- des données (name, text, width, height, ...)
- une vue qui récupère ses informations via le paint()
- un contrôleur via les events.

ton application a
- des données (genre mysql)
- une vue (ton ihm)
- un controleur, qui permet de dire à la vue ce qu'elle doit afficher.

On peut très bien faire un découplage total entre la vue, le contrôleur et les données en faisant en sorte que chacun ne voit que des interfaces.
On peut aussi tout coupler pour pas s'embêter.

Pour en revenir aux listeners swing, a mon avis ce code fait partie de la vue, qui le traite afin d'éventuellement le retourner au contrôleur si l'action n'est plus de sa responsabilité.
07/12/2010, 18h10
Zoners

Tous d'abord merci pour ta reponse.
"Pour en revenir aux listeners swing, a mon avis ce code fait partie de la vue, qui le traite afin d'éventuellement le retourner au contrôleur si l'action n'est plus de sa responsabilité."-->J'aimerai avoir un autre avis :p histoire d'être sur que je parte dans la bonne direction :)

Car moi ce que j'ai finalement fais(et ca me semble pas trop mal), c'est que j'ai envoyé au constructeur du controleur, la vue.
Cela me permet de gerer tous les listeners et actionPerformed. Et d'un autre coté je me dis que ce n'est peut être pas plus mal, je m'explique.

Le projet tels que je le vois:
-La vue elle va juste creer les boutons,menu,etc et s'occupe de les placers ou il faut.
-Le controleur lui s'occupe de gerer les evenements(listener et actionperformed) et verifie que les données sont bien correct pour le modele.
-Le modele pour les données.

Je me dis que ce concept me semble logique dans le sens ou je peus toujours changer mon interface sans avoir trop de repercussion sur le controleur(mais ca en aura tous de meme si je supprime des boutons ou menu de ma vue, d'un certains ces logique car la vue est tous de meme "un peu" lié au controleur vu que le controleur s'occupe des evenements).

J'aimerais bien aussi avoir d'autres avis ^^

Citation:

je peux toujours changer mon interface sans avoir trop de repercussion sur le controleur

Dans ton système, si tu change ton interface, il faut changer le contrôleur (ce n'est pas forcément une mauvaise chose), ce dernier se chargeant de faire communiquer la vue et les données ensemble.
Cela peut permettre de réutiliser la vue, ou les donnée avec d'autres contrôleurs.

Si on veut réutiliser le contrôleur, il ne doit pas connaitre la vue. Donc on ne passe pas ta vue en paramètre du constructeur, mais l'interface abstraite implémentée par ta vue. Ex bidon:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 interface Ui{ void drawMainView(Listener<QuitEvent> quitter, Listener<ValidEvent> valider); void drawGetId(Listener<IdEvent> getid); ... } interface Listener<T>{ void actionPerformed(T event); } class IdEvent{ String id; String passswd; String getId(){ return id; } String getPassword(){ return passwd; } } ...
main:
Code:

1 2 3 4 5 6 // on demarre le tour, genre Controleur c = new MonControleur(); c.setUi(new MonImplementationDeUi()); c.setData(new MonImplementationDeData()); c.start();
A noter que l'on peut faire l'inverse, passer le contrôleur à la vue pour qu'elle puisse utiliser les "algorithmes" du contrôleur pour répondre aux interactions utilisateur.