Discussion :

[rp37000]

Bonjour,

Je viens de tomber sur ce lien:
http://www.cyber06.com/article/mvc.php

Et quelque chose m'interpelle:

On voit dans cet exemple que le Contrôleur est quelque part observateur (listener) de la Vue:
La méhode actionPerformed() y est en effet écrite dans la classe Contrôleur!
Cela vous choque-t-il?
Est-ce normal, obligatoire, courant?

Non parce-que moi je plaçais cette méthode dans la Vue!


Merci pour vos avis.

[tristan_m]

Bonjour,

Pour ma part en tout cas, le seul point qui me gène un peu c'est la méthode getTexteTape().
Le reste me paraît correct.

En mettant le actionPerformed dans le contrôleur, on a l'impression que c'est le contrôleur qui reçoit les évènements utilisateurs.
Le diagramme de séquence montré amplifie cette impression d'ailleurs
Mais en l'occurrence c'est effectivement la vue qui envoie les actions utilisateur au contrôleur.
Seulement ici c'est implicite :

bouton.setActionCommand("modificationdevue");

Le controleur ne reçoit que "modificationdevue", pas une requête de type bouton.clic().
Donc jusque là pas de soucis pour moi.

En revanche personnellement j'éviterais de faire demander au contrôleur des infos à la vue (vue.getTexteTape()).
Donc au final je mettrais également le actionPerformed dans la vue et créerais une requête possédant les paramètres suffisant pour que le contrôleur n'ait pas à redemander derrière des données supplémentaires à la vue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

modificationdevue(texte.getText());

Ca aurait accessoirement l'avantage de ne pas avoir à faire un switch qui pourrait être important dans le cas d'un grand nombre de boutons.

[Patriarch24]

La méhode actionPerformed() y est en effet écrite dans la classe Contrôleur!
Cela vous choque-t-il?
Est-ce normal, obligatoire, courant?

La gestion des évènements étant le fait du contrôleur, cela ne me choque pas.

En revanche personnellement j'éviterais de faire demander au contrôleur des infos à la vue (vue.getTexteTape()).

Ceci est bien évidemment une erreur ! Normalement, le texte tapé dans l'interface aurait dû être récupéré via le modèle associé au champ texte !

[hegros]

Oui cela me choque car ce n'est pas le rôle d'un controleur que d'intercepter les événements bas niveau comme les clics et les saisies aux claviers. Il s'agit de responsabilités incombant à l'IHM.

Ce qui me choque encore plus c'est que le contrôleur implémente les WindowListeners....

Couramment ce que j'ai plutot vu c'est l'IHM qui écoute les événements de clic et dans la méthode actionPerformed on fait un Controleur.clicBouton1();

[tristan_m]

Bonjour,

Ceci est bien évidemment une erreur ! Normalement, le texte tapé dans l'interface aurait dû être récupéré via le modèle associé au champ texte !

Je ne pense pas que ce soit une erreur.
L'appel en question est fait par le contrôleur au moment où le bouton est cliqué.
Il demande alors à la vue quelle est la nouvelle valeur.
Il ne peut la récupérer que dans la vue, pas dans le modèle.

Le point que je soulevais c'est que je privilégierais une requête avec paramètres plutôt qu'une remontée d'évènement basique avec toutes les nouvelles données à récupérer aprés.
Ceci dit je pense que les deux façons de faire sont valables.

[rp37000]

Merci à tous pour vos interventions,


Déjà, ça me rassure de savoir que mettre actionPerformed() dans la Vue n'est pas une erreur: et pour ma part c'est la solution que je continuerai d'adopter. Ton avis en particulier hegros me conforte bien dans ce sens.

J'apprends également que le fait que le contrôleur soit LISTENER de la Vue
n'est pas -(en tout cas pas aux yeux de tous)- un crime, et que l'on resterait quand même dans du MVC.
Ceci dit je suis surpris que dans du MVC , on puisse avoir le Contrôleur OBSERVATEUR de la VUE, de façon aussi claire: implements ...listener !!
Ca vous choque vraiment pas du tout Patriarch24 et tristan_m ??!


-----------------

Concernant l'autre point:
Le fait que ça soit le Contrôleur qui aille demander à la Vue le texte tapé:
this.vue.getTextTape() MOI JE SUIS CARREMENT POUR à 200% !!

Pourquoi:

1-Tout d'abord: tout simplement parce-que la Vue n'a pas à savoir quelle information intéresse le Contrôleur lorsqu'elle va l'informer qu'un événement (1 Clic en l'occurence) vient de se produire: C'est au Contrôleur de savoir, au moment où il est prévenu de l'événement, les champs de la Vue qu'il souhaite lire: POUR MOI C'EST EVIDENT que c'est la meilleure(enfin ça semble logique non?! ) façon de faire.

2- Autre argument:
D'ailleurs si un jour les champs que doit lire le Contrôleur, suite au clic sur la Vue, changent: ben, pas besoin de modifier la Vue: juste le Contrôleur, puisque la Vue fera toujours son this.Controleur.clicSurBoutonX() tel quel, juste pour informer du clic !!!



Qu'en pensez-vous?

[hegros]

En fait j'en pense que c'est acceptable comme une des centaines de variantes qu'il peut exister.

Ce qui me gêne le plus c'est qu'en continuant à rendre responsable le controleur de toutes les événements de vue cela va en faire une classe poubelle car dans une application il n'est pas rare d'avoir plusieurs vues.

Autant je veux bien reconnaître qu'un des rôles du controleur soit la gestion des événements mais c'est plutot relatif à ceux du système et ce genre de chose.


Pour le texte tapé je rejoins rp37000. Le principe de base de MVC c'est séparation strict entre Modèle et Vue. Faire un vue.getText() dans le modèle est une erreur car le modèle ne doit jamais connaître la vue (avoir une instance).

Pour résumé, tant qu'on en reste à une application basique comme dans l'exemple cela reste bien entendu une conception correcte par contre dans le cas de plusieurs vues (des dizaines ou centaines) de domaine fonctionnel différent cela fait perdre de la cohésion au controleur et se serait fatalement une mauvaise conception.

[rp37000]

Hé hegros! bien sûr, bien sûr MAIS...

C'est pas dans le modèle qu'il s'agit de faire un this.vue.getText()!!
Heureusement... !
Mais dans le Contrôleur ....

Donc du coup quel est ton avis à toi sur ce point?

[hegros]

je n'y vois aucune erreur.

[rp37000]

Bon ben cool, si toi aussi tu penses qu'un this.vue.getTextTaped()
a tout à fait sa place dans le Contôleur IHM au moment où celui-ci est informé d'un événement (clic ici) par la Vue.

[hegros]

oui normal le contrôleur est chargé de la logique applicative donc...

[Patriarch24]

Je répète : le rôle du contrôleur est de gérer les évènements :

Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer.

(source : Wikipedia)

http://www.troika-asp.com/images/mvc_seq.gif


Conclusion : pas d'ActionListener dans la vue !

Quant au problème de getTextTape, je reviens sur ce que j'ai dit : si on n'a pas de système de mise à jour (outil de binding, pattern MVP -- model view presenter --), alors il incombe au contrôleur de récupérer les données de la vue. Mea culpa.

J'utilise beaucoup ces frameworks de binding, qui permettent de ne réfléchir qu'à la logique métier, et non plus à l'architecture MVC (en l'occurrence, MVPC ).

[hegros]

Faire gérer les événements de la Vue par le controleur cela retire finalement une indirection notamment le fameux controleur.frappeChiffre1() dans le actionPerformed lorsqu'on décide que c'est la vue implémente actionlistener cela me plait bien.


A vrai dire j'ai surtout vu des exemples de production où ce sont les IHM qui sont responsable des événements bas niveau et qui délégue au controleur mais bon cela revient finalement au même résultat c'est juste plusieurs variantes d'implémentation et d'organisation logique.


Je trouve cela réducteur de dire que le controleur a pour rôle seulement de gérer les événements il faut bien gérer la logique applicative en dehors de la logique métiers et de la logique ihm ce qui n'a rien à voir avec les événements quelques natures que se soit d'ailleurs le DS que tu as posté le montre bien

[rp37000]

Bonjour Patriarch24,


-Je suis rassuré que pour le getTextTape() tu aies changé ton point de vue.


-Concernant la position de la méthode actionPerformed():


->Par rapport à ce qui est écrit dans la définition supposée officielle du rôle du Contrôleur dans le MVC, et que tu cites:
(Je vais m'efforcer d'être objectif)

Pour le début de la définition:
"Le contrôleur prend en charge la gestion des événements"
Oui, pas d'ambiguïté: Le contrôleur interprète au final les évènements... ça
c'est clair.


Mais dans la fin de la définition:
"Le contrôleur reçoit tous les événements de l'utilisateur"

Là pour moi c'est AMBIGU:

Est-ce-qu'ils ont voulu dire:
"Le contrôleur reçoit DIRECTEMENT tous les événements de l'utilisateur".
Or,
"les événements de l'utilisateur" = évènements de bas niveau dans un 1er temps.
Et l'on sait bien que ce sont les composants de la Vue qui reçoivent en premier lieu les évènements bas niveau puis en informent leurs listeners.
Donc le sens de la phrase n'a pas pu être de façon tranchante:
"Le contrôleur reçoit DIRECTEMENT tous les événements de l'utilisateur".

Donc le sens de la phrase est du coup :
"Le contrôleur reçoit (sous-entendu PAS DIRECTEMENT) tous les événements de l'utilisateur".

- DONC, soit ça veut dire:
1- "Le contrôleur reçoit tous les événements de l'utilisateur DIRECTEMENT de la part des composants de la Vue, (contrôleur en listener direct)", auquel ça rejoint ton interprétation du texte. (DONC contrôleur OBSERVATEUR de la Vue: pour du MVC j'avais jamais lu ça nulle part, mais bon pourquoi pas...).

- OU soit ils ont plutôt, voulu dire, sous-entendre:

2- "Le contrôleur reçoit tous les événements de l'utilisateur de la part des composants de la Vue, après que celle-ci les ait captés(Vue en listener), puis traduits en appel à une méthode du Contrôleur (cette traduction s'effectuerait alors dans actionPerformed() de la Vue)".



Donc pour moi la définition que tu annonces:
"Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer."
reste ambigue, et donc ne répond malheureusement pas précisément et clairement à la question initiale:
"--> Où est la méthode actionPerfomed() ?".


Sachant que pour ma part, quand j'ai par exemple lu "Design pattern tête la
première" l'exemple MVC qu'ils donnent est avec actionPerformed() dans la Vue.
(Bon ceci dit: ils ne sont pas parole d'Evangile non plus, parce-qu'ils ont aussi
fait (l'équivalent de):
- Dans la Vue: this.controleur.setTextTape(this.widgetTextTape.getValue())
au lieu d'un this.vue.getTextTape() dans le contrôleur! Ce dont on parlé précédemment donc...)



A croire que TOUT LE MONDE n'est vraiment pas d'accord sur le MVC, et qu'en la matière la souplesse est relativement de rigueur!

Merci encore de ta participation Patriarch24.
J'avoue que je ne sais pas si un jour on va arriver à une conclusion ferme sur le sujet qui fait débât...

---------------------------------------

[rp37000]

Bonjour hegros, et merci pour ton avis,

Si j'ai bien compris, ta position est:

"Oui, actionPerformed() dans le Contrôleur, j'ai pas l'habitude mais finalement pourquoi pas"?


Si c'est bien ça, ben je vais finir par conclure que la réponse à ma question initiale est double, genre:
"actionPerformed() peut-être écrite dans le Contrôleur ou dans la Vue, chacune de ces façons de faire ayant ses avantages et inconvénients"


Ca doit être ça non, qu'en pensez-vous??


--

[pseudocode]

Si c'est bien ça, ben je vais finir par conclure que la réponse à ma question initiale est double, genre:
"actionPerformed() peut-être écrite dans le Contrôleur ou dans la Vue, chacune de ces façons de faire ayant ses avantages et inconvénients"


Ca doit être ça non, qu'en pensez-vous??

La gestion "bas niveau" des IHM (en java,.net,qt,...) n'est pas le modèle MVC mais le modèle Form/Action. En gros, c'est un système évènementiel : une action "utilisateur" génère un objet évènement qui est mis dans une queue. Une thread "cachée" s'occupe de dépiler les évènements et d'exécuter les méthodes adéquates.

Donc le couple Widget+ActionPerformed est un Form/Action au niveau de l'implémentation. Le modèle MVC doit être codé "au dessus" du modèle Form/Action.

- On peut découpler les 2 implémentations:

• Modèle = classe dédiée "MonModèle"
• Vue = classe du framework de type Form/Action
• Controleur = classe dédiée "MonControleur"

- On peut coupler complètement les 2 implémentations:
MVC = classe du framework de type Form/Action

• attributs spécifiques de la classe: modèle
• attributs des widgets : vue
• méthodes de la classe : controleur

on peut aussi mixer les 2 couplages.

[rp37000]

Je ne comprends pas tout ce que tu dis là Pseudocode, mais ça a l'air de vouloir dire que les 2 cas sont envisageables pour la position de actionPerformed().


En tout cas Merci.

[Keihilin]

Il ne faut pas oublier le but, où plutôt l'un des buts, des patterns MCV, MVP ou apparentés : rendre la logique de présentation testable.

Dans cette optique, moins l'implémentation réelle de la vue (dont le contrat devrait être défini dans la même couche que les contrôleurs) a de comportement, plus la couverture de tests augmente; l'idéal étant d'arriver à des vues dénuées de tout comportement et se contentant de signaler les actions de l'utilisateur au(x) contrôleur(s) associé(s) (Fowler parle de Humble Views).

Conclusion : actionPerformed() dans le contôleur, surtout pas dans la vue...

[rp37000]

Bonjour Keihilin, et merci de ton intervention,

Ce que tu dis là m'intéresse, et je trouve que les arguments que tu apportes sont séduisants.
En gros tu dis: La Vue doit être la moins intelligente possible , en effectuant un minimum de traitement, et en se concentrant UNIQUEMENT sur de l'AFFICHAGE.

J'avoue que ça donne à réfléchir et pour moi à reconsidérer mon point de vue.

En réalité je dis que tu portes dans cette phrase la raison et la conclusion de cette discussion, mais qqch me retiens encore de procéder ainsi, intuition... je sais pas!

J'attends peut-être plus de réactions appuyant ce point de vue que tu délivres.... Donc très intéressant mais à confirmer par d'autres...

J'ai envie de dire qui est pour?? :o)

[Keihilin]

En gros tu dis: La Vue doit être la moins intelligente possible , en effectuant un minimum de traitement, et en se concentrant UNIQUEMENT sur de l'AFFICHAGE.

En gros oui, c'est l'approche que j'ai décidé de suivre le plus souvent possible.

C'est peut être particulièrement vrai pour les technologies avec lesquelles je travaille habituellement (asp.net), mais cela l'est aussi pour des tas d'autres : la logique de présentation est difficilement réutilisable et la couche de présentation est difficilement testable.

Pour résoudre ces deux problèmes, il convient de limiter le plus possible le comportement des vues.

Dans mon approche, une vue est d'abord définie par une interface comportant propriétés et événements "neutres" (càd des événements qui ne sont pas spécifiques à une implémentation concréte, asp ou winforms par exemple).

L'implémentation (une page aspx par exemple) se contente de faire la liaison entre les propriétés définies dans l'interface et les contrôles utilisateur (textbox, dropdownlist, etc...) d'une part et les événements "neutres" et les événements spécifiques (genre click sur un bouton) d'autre part, mais rien d'autre.