Discussion :

[rp37000]

Bonjour à tous et à toutes,


J'essaye de me faire une petite synthèse de ce que je crois avoir compris
du MODELE MVC standard, pourriez-vous me dire si j'ai bien compris, si ce que je dis est juste , si je n'oublie rien,
MERCI beaucoup pour votre aide et vos critiques .



LES ROLES:

- LE MODELE:

. Représenter et encapsuler les données d'une LOGIQUE METIER et offrir
à l'extérieur des moyens de lire et d'en modifier certaines.


- LA VUE:

. Permettre à l'utilisateur d'avoir une représentation VISUELLE du
MODELE ou d'une partie du MODELE, la plus à jour possible.
Une VUE est donc spécifique à un MODELE donné.

.Permettre à l'utilisateur d'interagir avec le MODELE
(Demandes de: modif, ajout, suppr, visu)


- LE CONTROLEUR:

. Recevoir les Demandes de l'utilisateur que lui transmet donc la VUE, les
interpréter vis-à-vis du MODELE, les filtrer, les contrôler.

. Demander au MODELE de se mettre à jour (modif, ajout, suppr).

. Implémenter la LOGIQUE graphique de la VUE: griser tel widget si tel autre
... .



MISE EN OEUVRE


- LE MODELE:

. Le MODELE est observable directement par une ou plusieurs
VUES. Dans les faits, les VUES sont les seules observatrices du MODELE.

. Le MODELE sait qu'il peut avoir des observateurs pour chacune de ses
propriétés. Il gère donc une liste d'observateurs par propriété X qu'il
possède(et souhaite rendre lisible), il possède donc autant de méthodes :
.notifyObservers_DeLaProprieteX()
.addObserver_DeLaProprieteX( IObserver_ProprieteX objet)
.removeObserver_DeLaProprieteX( IObserver_ProprieteX objet)
.Les observateurs d'une propriété X devront s'enregistrer en tant que tel
auprès du MODELE en faisant un appel du syle:
this.modele.addObserver_DeLaProprieteX( this ).
Et ces observateurs-ci devront donc implémenter une interface
IObserver_ProprieteX contenant une méthode
updateWidget_PourLaProprieteX(), que la méthode
notifyObservers_DeLaProprieteX() du MODELE pourra alors appeler
pour leur signifier le changement de sa ProprieteX.


.Le MODELE implémente une interface genre IModele_get contenant des
méthodes de lecture du MODELE (get()), permettant ainsi à un
observateur de l'interroger, par exemple:
(vue.widgetPourProprieteX.value=vue.modele.getProprieteX()...)

.Le MODELE implémente une interface genre IModele_set contenant des
méthodes d'écriture sur le MODELE (add(), set(), del()),
permettant ainsi au CONTROLEUR(uniquement) de
pouvoir le modifier directement.


- LA VUE:

.La VUE sait mettre à jour toute seule ses champs par simple appel
direct des méthodes get() que le MODELE met à disposition de ses
observateurs (le modele implémentant IModele_get).
La VUE voit le MODELE uniquement comme étant de type IModele_get.
La VUE ne peut ainsi que CONSULTER le MODELE (pas de modif!).
La VUE se met à jour, soit pour initialiser le contenu de ses champs,
soit sous sollicitation du MODELE qui l'informe d'un changement des
données qui la concerne (et donc pour lesquelles la VUE s'était enregistrée
en tant qu'observatrice).
.La VUE implémente une interface IObserver_ProprieteX pour chaque
propriété X du MODELE qu'elle souhaite observer.
La VUE possède donc une méthode updateWidget_PourLaProprieteX()
que son MODELE invoquera pour signifier le changement de la propriété X.
Mais la VUE peut elle même, au moment de l'initialisation de ses champs,
faire appel à sa méthode updateWidget_PourLaProprieteX() pour initialiser
la valeur contenu dans le Widget représentant visuellement la propriété X.

.La VUE connait le CONTROLEUR, et pour elle le CONTROLEUR est de
type IController (interface que devra implémenter le CONTROLEUR
concret). Cette interface contient des méthodes que la VUE invoquera
suite à une action de l'utilisateur. La VUE pourra ainsi dire à SON
CONTROLEUR que l'utilisateur demande telle modif. sur le MODELE:
this.controller.demandeModif_ProprieteX().

.La VUE peut également implémenter une interface IVUE
qui permettra à son CONTROLEUR de la mettre à jour d'un point de vue
LOGIQUE graphique: griser , rendre (in)visible, tel widget, etc... .
Ainsi le VUE pourra par exemple posséder une méthode
setWidget1_visibility(boolean).



- LE CONTROLEUR:

. Implémente une interface IController, permettant d'offrir des méthodes
à la VUE pour qu'elle puisse transmettre au CONTROLEUR les demandes
de l'utilisateur.

. Pour le CONTROLEUR, la VUE est de type IVUE, à savoir elle implémente
l'interface IVUE, il peut donc agir sur la LOGIQUE graphique de cette
dernière: par exemple, this.vue.setWidget1_color( errorColor ) .

. Pour le CONTROLEUR, le MODELE est de type IModele_set, à savoir que
ce dernier implémente IModele_set (un ensemble de méthodes que le
MODELE met à dispo. pour qu'on puisse le mettre à jour).
Le CONTROLEUR peut donc ordonner des modifs sur le MODELE:
this.modele.setProprieteX( newValue ) .

. Le CONTROLEUR n'a pas besoin de lire le MODELE ....?
Il se contente juste de le mettre à jour car c'est la VUE qui interrogera
le MODELE .


Voilà j'espère que je n'ai rien oublié de ce que j'en pense .



MERCI beaucoup pour votre participation, vos remarques et critiques.

[rp37000]

Et un petit diagramme de classes pour résumer.

[tristan_m]

Bonjour,

D'abord bravo pour ce travail de synthèse, c'est pas forcément évident d'appréhender tout un système de cette façon.

Pour répondre à ton message, je n'aborderais pas trop l'implémentation car je pense que c'est plus au développeur de décider ce qu'il y a de plus simple/maintenable/rapide à réaliser selon les critère extérieurs (environnement de développement, client impatient, etc...).

En revanche j'ai noté deux trois points qui sont à appronfondir si l'on souhaite respecter le modèle MVC scrupuleusement.
D'abord une doc. que j'aime citer en référence :
http://java.sun.com/blueprints/patte...-detailed.html

Le premier je pense, c'est plus un problème de description je pense :

Une VUE est donc spécifique à un MODELE donné.

Il est évident que les interfaces modèle et vue doivent être cohérentes. On ne vas pas poser une vue d'une horloge digitale sur un modèle d'un lecteur multimédia .
En revanche, le principe de MVC est de pouvoir changer de modèle /vue / controleur sans que les autres composants soient impactés. Donc plusieurs modèles peuvent correspondre à une seule vue, si tant est que les interfaces correspondent.


Le deuxième point est peut être discutable également. Dans le diagramme, je vois que la vue possède une instance du modèle. Même si la vue n'a accès qu'à des propriété "get", en principe ce ne devrait pas être le cas.

Dans ce que j'ai compris du pattern observateur, c'est l'objet observé qui notifie ses observateurs qu'il y a eu une modification. C'est donc l'objet observé qui possède des références vers ses observateurs, et pas l'inverse.



Enfin, à propos du contrôleur, je ne suis pas sur du tout d'avoir raison mais j'ai une vision différente de son fonctionnement.

Pour le CONTROLEUR, la VUE est de type IVUE, à savoir elle implémente
l'interface IVUE, il peut donc agir sur la LOGIQUE graphique de cette
dernière: par exemple, this.vue.setWidget1_color( errorColor ) .

Ce point est TRES discutable, mais dans le principe, Le contrôleur ne peut que décider de changer de vue. Pour reprendre l'exemple de la montre, c'est au contrôleur de décider si on passe d'une vue horloge digitale à une vue horloge à aiguille. En revanche au sein de la vue, il ne doit pas avoir d'influence. La théorie voudrait alors qu'il y ait une vue spécifique avec le bouton grisé...

. Le CONTROLEUR n'a pas besoin de lire le MODELE ....?
Il se contente juste de le mettre à jour car c'est la VUE qui interrogera
le MODELE .

Le contrôleur n'a pas besoin de lire le modèle : oui.
J'aurais même envie de dire : il ne DOIT pas.

Par contre, comme dit sur le point 2, ce n'est pas la vue(observateur) qui va interroger le modèle (observé). Normalement la vue ne doit pas connaître le modèle.
Lorsque le modèle notifie à la vue qu'un changement s'est produit, alors la vue va demander au modèle (passé en argument) quelles sont les modifications produites, et se mettre à jour en conséquence.


Voilà, encore une fois j'ai peut être tort sur ce que j'ai énoncé, en tout cas c'est ce que j'ai compris de MVC.
N'hésite pas si tu as des questions supplémentaires sur des points que j'aurais mal expliqués.

Bon courage!

[rp37000]

Bonjour tristan m,


Merci beaucoup d'avoir pris du temps pour venir enrichir cette discussion et partager tes perceptions et ton expérience.

Le lien que tu me proposes , résume bien ce que de mon côté j'avais saisi sur le MVC.


Pour ta part, tu me dis:
"plusieurs modèles peuvent correspondre à une seule vue, si tant est que les interfaces correspondent."

Je suis d'accord avec cela, disons, dans le cas d'une vue plus généraliste permettant donc de représenter visuellement des modèles différents. Auquel cas on aurait à faire à une vue paramétrable (les libellés métiers notamment).
Je ne crois pas pourtant qu'il s'agisse du cas le plus fréquent, mais idéalement ce serait effectivement top d'avoir un minimum de vues utilisables pour un max de modèles!! Je pense qu'on resterait malgré tout sur du MVC.


A propos du pattern observateur, tu me dis:
"...C'est donc l'objet observé qui possède des références vers ses observateurs, et pas l'inverse."
Effectivement l'observé (le modèle) contient des références vers ses observateurs (vues) et le modèle sait juste
que ses observateurs implémentent une certaine interface (dans mon exemple: IObserver_proprieteX, IObserver...Y, ...),
il se fiche en effet de connaître le type concret de ses observateurs. Donc là on est d'accord.
PAR CONTRE, concernant le fait que l'observateur n'est pas de référence vers son sujet observé, il est plus que possible qu'au contraire il en possède une (passée à son constructeur).
Et là je m'appuie sur ce que j'ai lu dans 3 bouquins:
-"Design patterns tête la première": page 68.
-"Design pattern les 23 modèles de conception" de DEBRAUWER: page 248.
-"Design patterns , catalogue de modèles de conception réutilisables" du Gang Of Four: page 345, 353 .

Mais je crois qu'avant tout, en la matière il y a souplesse: on peut rester dans le pattern observateur en faisant:
-Aussi bien ça (cas 1):
l'observateur ne connaît le modèle que ponctuellement par le biais d'un appel de ce dernier, lorsque le modèle fait: this.observers[n].update(this) , il se transmet lui-même en param. à l'observateur,
qui lui, implémente la méthode update(IModele), laquelle attend pour type un IModele (IModele_get dans mon exemple).
Auquel cas l'observateur une fois notifié va faire un: this.monWidget.value=modeleRecuEnParam.getDataSouhaitee() pour
pouvoir récupérer auprès du modele la valeur à imputer à son Widget.

-Que ça (cas 2):
Comme indiqué sur mon Diagramme: l'observateur (vue) possède une(des) référence(s) vers son(ses) sujet(s) (observé(s)).
Il a donc juste à faire un this.monWidget.value=this.modele.getDataSouhaitee() une fois update() appelée.
On remarquera que dans ce cas là, la méthode update() n'a pas de param. (mais ça pourrait... cf. parenthèse ci-dessous).

(Petite parenthèse sur le Pattern Observateur, en passant:
on peut avoir des cas où un observateur observe plusieurs sujets).

Enfin, à propos de l'initialisation du contenu des champs de la Vue:
celle-ci n'est à priori pas initiée(notifiée) par le modèle car au début le modèle ne subit pas forcément un changement d'état que qqch aurait suscité: donc pour son initialisation, la Vue doit être capable de renseigner le contenu de ses champs sans bénéficier de la notification du modele.
Alors dans le cas 1: on peut imaginer que le Contrôleur lui dit : initialise-toi en lui transmettant le modele en param. .
Et dans la cas2: la Vue connaît déjà le modèle donc elle sait se mettre à jour toute seule.

On notera quand même que dans le MVC , l'idée c'est que : c'est la VUE qui, pour pouvoir renseigner ses propres champs, interroge directement le MODELE (modele.getData()). Et que dans le cadre particulier de son initialisation, la Vue interroge le modele sans que celui-ci l'en ait notifié!
Je ne pense pas raconter de bêtises là ( vu dans le bouquin de DEBRAUWER, p. 248).




Concernant le fait que le Contrôleur implémenterait la LOGIQUE de la Vue:
En fait je veux effectivement dire qu'à travers des méthodes de l'interface IVue le Contrôleur demande à la Vue de se modifier, la Vue s'éxécute alors sans broncher, et d'une façon totalement opaque(Swing, AWT,...)
pour le Contrôleur, elle effectue la modif. GRAPHIQUE correspondant à l'ordre du Contrôleur.

Si j'ai bien compris? : toi tu as compris que:
* Un Etat donné d'une Vue de Base => Une Vue différente
* Et que le Contrôleur fait 2 choses:
- Recevoir les demandes que l'utilisateur effectue via les composants de la Vue. (Vue-->Controleur)
- Ordonner les changements de Vue. (Vue<--Controleur)

J'avoue que personnellement je n'adhère pas: ça ferait trop de Vues.
D'après ce que j'ai compris le Contrôleur est le CERVEAU, la LOGIQUE de la Vue, c'est lui qui donne les ordres à celle-ci:
il lui dit via une Interface: "fais ça et tais-toi!" et la Vue fait avec les moyens du bord prévus.
Tu noteras que ça n'enlève en rien le fait que le Contrôleur n'ait pas besoin de savoir comment la Vue s'y prend CONCRETEMENT pour le faire.
L'important je crois et que la Vue et le Contrôleur communiquent via Interface (IController et IVue)
et que la tambouille interne et concrète de chacun ne regarde plus l'autre.

-Un Contrôleur1 concret dira à la Vue1, via l'interface IVue : "Grise ton bouton 'Ajouter'", et la Vue1 grise la bête...
-Un autre contrôleur, Contrôleur2 concret dira à la même Vue1, via l'interface IVue : "Grise ton bouton 'Ajouter'", et la Vue1 grise aussi la bête...
Mais la différence c'est que le Contrôleur1 ne le dira pas forcément pour les mêmes raisons(Trop d'ajouts faits, Heure dépassée,...) que le Contrôleur2:
ce qui varie entre les 2: la LOGIQUE de l'interface graphique, pour une MEME Vue donc!
Pour une Vue donnée, le CONTROLEUR est UNE STRATEGIE(une façon d'implémenter la LOGIQUE de la Vue):
une même VUE => n STRATEGIES <=> n Contrôleurs .
(cf. Pattern STRATEGY).
Enfin voilà là-dessus je pense encore être dans le vrai, sur le bon chemin.
Mais j'avoue que c'est pas facile de définir une frontière ferme et carrée entre ce qui est uniquement du ressort de la Vue et ce qui est uniquement du Ressort du Contrôleur.


Enfin, je reviens sur un point, j'ai dit:
"Le CONTROLEUR n'a pas besoin de lire le MODELE ....?"
et bien je reviens sur cette pseudo-intuition que j'avais, je change mon fusil d'épaule et je dis:
Je pense que le Contrôleur devrait avoir la possibilité(si besoin) d'interroger -(en plus de le mettre à jour)- le modele,
dans certains cas, et pour son propre compte, pour son propre raisonnement interne, MAIS PAS pour mettre directement à jour la Vue on est
bien d'accord, ce serait juste pour nourrir la Stratégie qu'il implémente.


Encore Merci tristan m,
tu soulèves des points qui méritent réflexion et apporte de l'eau au moulin.

[tristan_m]

Bonjour,

J'avoue avoir fait moins de recherche bibliographique sur le sujet, aussi j'aurai vite du mal à soutenir cette discussion.

A propos du pattern observateur, je me suis basé sur le livre du GoF uniquement. L'exemple d'implémentation utilise la cas 1 que tu as décris, donc pas de référence à l'observé dans l'observateur. (stockée tout du moins).

Maintenant c'est vrai qu'il ne s'agit que d'implémentation, la littérature que j'ai pu lire n'étant pas suffisamment claire ou conséquente sur l'intérêt de l'une ou l'autre méthode. En tout cas je serai moins catégorique sur ce point à l'avenir


Au sujet de la vue qui interroge le modèle, l'idée que tout parte du modèle me plait pour au moins une raison : Pas besoin de polling. Il est plus efficace en général d'effectuer une modification sur réception d'un évènement que d'interroger une base tous les deltas de temps pour savoir si une modification a eu lieu.
Aprés bien sur rien n'empêche de faire un système plus intelligent qui saurait faire les deux de façon optimisée.

Quant à l'initialisation, il suffit d'envoyer une notification à l'observateur au moment ou il s'enregistre. La vue est alors automatiquement à jour dés qu'elle est enregistrée comme observateur du modèle.



Pour le controleur, j'y ai repensé et effectivement il y a une autre façon de faire qu'une vue spécifique.
La vue représentant le modèle, c'est le modèle qui doit intégrer la modification (et notifier la vue en cas de changement).
Ca m'embête un peu que le contrôleur puisse changer l'état d'une vue. Comment une autre vue aurait connaissance de ce changement?

Je suis entièrement d'accord sur le fait que le controleur soit une stratégie pour la vue. Le controleur représente la logique du logiciel dans le sens ou c'est lui qui dicte au modèle quelles actions il doit opérer, et si un bouton doit être grisé, c'est au modèle (qui définit les lois de fonctionnement) d'en décider. Je ne pense pas que le contrôleur doive "bypasser" le modèle.

Personnellement je vois plus le contrôleur comme un cablage qui indique quelle action doit être réalisée en fonction de l'évènement reçu par la vue. Typiquement le contrôleur aurait tout bénéfice à être implémenté dans une machine à état, chaque état représentant une stratégie.



Enfin pour le dernier point, je vais faire comme toi et changer mon fusil d'épaule
Bien que ce que j'ai pu lire n'indique jamais ce genre de requête, je ne vois pas comment le contrôleur peut tout maîtriser sans avoir une idée (ou au moins une demande de confirmation) de l'état du modèle. Comment le contrôleur peut savoir si une demande de changement a marché (et éventuellement passer dans un état différent)? si oui quelle est la nature du changement?
Ou alors passer par la vue qui enverra au contrôleur un évènement d'acquittement lors de la notification du modèle........
J'avoue que je ne vois pas ce qui justifierait un système si complexe.


Sinon je tiens également à te remercier de me faire revoir mes affirmations. Ca m'aide aussi à clarifier certains points pas toujours très clairs dans mon esprit (ou clairs mais faux )

[rp37000]

Bonjour tristan_m, et merci pour tes réflexions.


Le pattern observateur évite justement ce fameux:
"interroger le modele tous les deltas de temps pour savoir si une modification a eu lieu". On est bien d'accord.
Et pour l'initialisation de la vue: Merci pour l'idée, je suis preneur.
"il suffit d'envoyer une notification à l'observateur au moment ou il s'enregistre." plutôt que la Vue fasse appel elle-même à sa propre méthode update().



Je ne comprends pas ce qui te gêne EXACTEMENT quand tu dis:
"Ca m'embête un peu que le contrôleur puisse changer l'état d'une vue. Comment une autre vue aurait connaissance de ce changement?"
Et en plus je ne sais pas quoi te répondre??




Tu dis:
"Le controleur représente la logique du logiciel dans le sens ou c'est lui qui dicte au modèle quelles actions il doit opérer, et si un bouton doit être grisé, c'est au modèle (qui définit les lois de fonctionnement) d'en décider. Je ne pense pas que le contrôleur doive 'bypasser' le modèle."
Ben là... , j'adhère carrément pas !

Le modele ne connaît jamais la Vue en tant que Vue mais uniquement en tant qu'objet observateur implémentant une interface (dans mon exemple IObserver_...). Le modèle contient les LOIS de fonctionnement propre au METIER, pas celles de la VUE!! C'est justement le contrôleur qui gère ce dernier point!
A mon sens, le CONTROLEUR ne représente PAS la LOGIQUE du modele, c'est-à-dire qu'il ne représente PAS la LOGIQUE METIER, surtout pas: c'est le MODELE qui intègre cette LOGIQUE METIER, et le CONTROLEUR s'en bat les cacahuètes je pense. Le CONTROLEUR intègre juste la LOGIQUE de L'INTERFACE GRAPHIQUE vis-à-vis des conséquences sur le modele: c'est PAS la même chose. Le modele ne cherche jamais à modifier la Vue, il met juste à disposition des valeurs que pourront venir chercher des observateurs quelconques lorsqu'il leur dira: pas des valeurs de Grisage ou non, de looking, etc ... d'un bouton ou autre, mais des valeurs représentant le modele indépendemment de toute notion de Vue: un nombre, une chaîne de caractères, une liste d'entités, et même un booléen.

Exemple: le modele intègre la logique de calcul d'un intérêt sur emprunt, lui-même conditionné par une autre valeur propre au modele: ça, c'est la logique intrinsèque et propre au modele: le controleur s'en contre-fiche.
Maintenant admettons q'un bouton de la Vue doive être grisé lorsque le résultat du calcul est supérieur à un montant mntMax donné.
Tout d'abord, selon moi : mntMax est à stocker dans le Contrôleur (car il va s'agir d'implémenter une logique, une stratégie d'affichage: Griser un bouton SI ...).
(Ainsi pour cette même Vue, si on change le Contrôleur, alors on change la STRATEGIE et on peut par exemple avoir un mntMax différent, par exemple parce-que 2 de nos (gros) clients souhaitaient que sur ce point l'interface graphique en question offre une logique et des mntMax différents et personnalisés: donc pour la même Vue, juste le Contrôleur différe (1 par client), et bien sûr entre les 2 clients le modele n'a pas bougé d'un iota, et n'a jamais demandé à Griser un quelconque bouton!).
.
Mais alors on peut se poser la question:
Comment fait le Contrôleur pour savoir que le montant calculé
- (et qui n'est connu que de la Vue, puisque c'est elle seule qui est allée le récupérer ( modele.getData() ) auprès du modele) -
est supérieur au montant mntMax qu'il est lui le seul à connaître?
Ben là j'imagine qu'on pourrait:
Faire en sorte que la Vue appelle systématiquement une méthode du Contrôleur chaque fois qu'elle met à jour son champ Montant Calculé.
Le Contrôleur alors informé, va demander à la Vue de lui renvoyer le Montant
affiché dans le champ, par un this.vue.getChampXValue() (avec this: le Contrôleur), et là le Contrôleur comparera la valeur Mnt reçue avec le mntMax qu'il est le seul à connaître, et SI Mnt>MntMax alors le contrôleur invoquera la méthode de Grisage du bon bouton, la Vue s'éxécutera alors et grisera ce dernier.
Pour moi la Vue n'a pas de CERVEAU, de STRATEGIE, elle raisonne pas
(elle résonne elle fait echo de ce qui lui arrive): elle informe juste son CONTROLEUR de ce qui lui arrive, et le CONTROLEUR lui traduit cela soit:
-en modif. à effectuer sur le modele,
-soit en répercussions graphiques (présentation, activation/désactivation de menus,...) sur la Vue. <<< Je ne dis pas que le Contrôleur doit renseigner sur la Vue des valeurs propres à représenter le modele!


Voilà je reste sur cette vision, pour faire une petite analogie, je dirais:
C'est mon point de VUE, ma façon de présenter le MODELE(read-only) que l'on nomme MVC, .



Tu dis:
"Personnellement je vois plus le contrôleur comme un cablage qui indique quelle action doit être réalisée en fonction de l'évènement reçu par la vue."
C'est une vision intéressante je pense, CEPENDANT à mon sens le rôle du CONTROLEUR ne se limite pas qu'à cela (juste à câbler ou non (ON/OFF) un ordre reçu de l'utilisateur vers une méthode du modele), le rôle du Contrôleur à mon sens, est aussi d'effectuer des raisonnements destinés à impacter la présentation graphique de la Vue, comme explicité plus haut.
Mais là je crois qu'on n'arrive pas à se rejoindre.

PEUT-ETRE l'avis d'une tierce personne pourrait donner matière à conclure
ou approfondir sur ce point!




Tu dis:
"Typiquement le contrôleur aurait tout bénéfice à être implémenté dans une machine à état, chaque état représentant une stratégie."
Je trouve ton idée intéressante, mais resterait à déterminer pourquoi le Contrôleur devrait changer d'état, de Stratégie dynamiquement donc, au cours de l'application? (Je ne pense pas que ça puisse être du fait d'un changement de Vue, car d'une Vue à l'autre le Contrôleur n'a pas forcément les mêmes méthodes à implémenter, donc on ne serait plus dans le pattern Etat, (dans lequel tous les états doivent implémenter les même méthodes )).


Enfin, concernant le dernier point que tu évoques:
"Enfin pour le dernier point, je vais faire...."
C'est effecivement cette solution que j'expose dans mon exemple juste ci-dessus (le Controleur est informé par la Vue que le mnt calculé a changé, il l'interroge alors la Vue pour comparer ce mnt avec le mntMax qu'il connaît, etc...). J'en vois pas d'autre. (J'avoue que ça ressemble un peu à une observation ponctuelle de la Vue par le Controleur).


Voilà ce que je trouve à dire, en rapport avec les divers points que tu soulèves ,en ce qui me concerne ça s'éclaircit, donc merci à toi tristan_m pour les visions, les vues que tu proposes du Modele MVC.
J'espère que pour toi et d'autres ça s'éclaircit aussi, et que que l'on ne sème au contraire pas le trouble dans les esprits!

Je reste à l'écoute(observateur) pour tout point de Vue rejoignant ou, divergeant avec tout ça.

Toutes les réflexions seront les bienvenues, le but restant d'éclaircir, d'enrichir et d'essayer de couvrir la diversité des points de vue en matière de MVC.

Un grand MERCI à tristan_m et à tous ceux qui souhaiterait intervenir.

[tristan_m]

Bonjour,

Tu dis:
"Le controleur représente la logique du logiciel dans le sens ou c'est lui qui dicte au modèle quelles actions il doit opérer, et si un bouton doit être grisé, c'est au modèle (qui définit les lois de fonctionnement) d'en décider. Je ne pense pas que le contrôleur doive 'bypasser' le modèle."
Ben là... , j'adhère carrément pas !

Evidemment que ce n'est pas le modèle qui va explicitement demander à la vue de griser son bouton avec une variable du type isBoutonDisabled.

Ce que je disais c'est qu'à mon sens le fait que le bouton de la vue soit grisé doit être malgré tout interprété d'une variable dans le modèle.
Le fait qu'une valeur soit en rouge ou en vert ne doit effectivement pas explicitement être décrit dans le modèle, mais rien n'empêche d'avoir un indicateur d'anormalité, qui pourra de toute façon servir dans le reste du modèle.
La vue traduira aprés cette variable comme elle veut, ce n'est effectivement pas le problème du modèle.

Dans ton exemple, la façon dont je procéderais serait de créer une variable booléenne isAboveMntMax dans le modèle indiquant si le mntMax est dépassé. Le mntMax étant par ailleurs, pour moi, une donnée du modèle.
La vue va alors refléter le fait que le mntMax soit dépassé par le "grisage" du bouton, en récupérant la valeur de isAboveMntMax.
Cette variable servirait accessoirement de garde fou au cas où le grisage du bouton ne serait pas effectif en cas de bug, de cas imprévu, ou d'attaque.

... Mais il semble effectivement que nos points de vue ne convergent pas sur ce point.

Il me semble d'ailleurs un peu dangereux que cette sécurité soit de la responsabilité du contrôleur. Si une commande ne doit pas être lancée, le modèle doit savoir dire qu'elle est invalide, pas seulement être aux ordres du contrôleur.
Si le composant qui est en charge de la modification implémente lui même les mécanismes de sécurité, il y a beaucoup moins de risques d'erreur.

Je ne comprends pas ce qui te gêne EXACTEMENT quand tu dis:
"Ca m'embête un peu que le contrôleur puisse changer l'état d'une vue. Comment une autre vue aurait connaissance de ce changement?"

Je ne dis pas que le Contrôleur doit renseigner sur la Vue des valeurs propres à représenter le modele!

Ce que tu suggères dans cette dernière phrase c'est que certains aspects de la vue soit dictés exclusivement par le contrôleur (griser un bouton par exemple) et que d'autres soit dictés par le modèle (les données numériques par exemple).
C'est ça qui me gène.
Je vais donc expliquer plus précisément pourquoi.
Supposons que tu aies 3 vues possibles pour représenter ton emprunts :

• Avec uniquement des données numériques
• Avec des histogrammes
• Avec des camemberts

D'abord tu utilises une vue avec des données numériques pour rentrer ta simulation. A un moment le contrôleur demande au bouton de se griser. OK.
Juste aprés tu veux ouvrir une nouvelle vue avec des histogrammes pour vérifier certains points qui sont plus clairs sur cette vue.
Comment cette vue pourrait savoir que le fameux bouton doit être grisé?
Selon ce que j'ai compris danstes explications, il faut d'abord qu'elle récupère ses valeurs auprés du modèle, puis qu'elle envoit des évènements à partir de ces mises à jour au contrôleur qui alors va griser le bouton.
Ca me paraît réalisable en effet, mais bien compliqué et en gros ça revient à faire deux fois la même chose mais auprès de deux objets différents (le modèle et le contrôleur).



Bref, j'ai l'impression que nous ne sommes tout simplement pas d'accord sur le rôle du contrôleur.
Pour ma part j'estime que la vue ne doit refléter QUE le modèle, alors que tu attribues plus de responsabilités au contrôleur.

J'avoue pour ma part que le contrôleur est la partie la plus floue du MVC, aussi je ne suis pas catégorique du tout sur le fait que ma vision des choses soit celle à adopter. A l'heure actuelle

C'est mon point de VUE, ma façon de présenter le MODELE(read-only) que l'on nomme MVC.

Bon courage!

[rp37000]

Bonjour tristan_m,



Si j'ai bien compris ton point de vue est:
"La vue décide elle-même si elle doit ou non griser un bouton , par exemple,
et ce n'est pas au contrôleur d'ordonner à la vue de le faire, mais à la vue
de prendre elle-même selon sa logique interne de présentation, cette décision"
Tu attribues donc un UNIQUE rôle au contrôleur celui de:
"câbleur conditionnel qui indique quelle action doit éventuellement être réalisée en fonction de l'évènement reçu par la vue."
Du coup tu attribues à la vue un autre rôle , celui de gérér elle-même sa logique d'affichage (griser tel SI ..., colorer tel SI ...).


Quant à moi, je disais effectivement que:
"Cette logique -(griser oui ou non, colorer oui ou non, ... SI ...)- de présentation de la vue,
que je qualifierais aussi de stratégie (interchangeable) doit être gérée par le contrôleur de la vue."
J'attribuais donc pour ma part, ce rôle supplémentaire au Contrôleur.



Tu dis:
"Comment cette vue pourrait savoir que le fameux bouton doit être grisé?
Selon ce que j'ai compris dans tes explications, il faut d'abord qu'elle récupère ses valeurs auprés du modèle, puis qu'elle envoit des évènements à partir de ces mises à jour au contrôleur qui alors va griser le bouton.
Ca me paraît réalisable en effet, mais bien compliqué et en gros ça revient à faire deux fois la même chose mais auprès de deux objets différents (le modèle et le contrôleur)."
--->Effectivement j'aurais procéder ainsi .



**** FINALEMENT *******************
********************************************
Je trouve cependant ton idée plus qu'intéressante, quand tu parles de mettre la valeur mntMax dans le Modèle plutôt que dans le contrôleur.
(Auquel cas, avec mon idée de départ, j'aurais fait en sorte que le contrôleur connaisse cette valeur par un this.modele.getMntMax() pour contrôler la vue sur ce point).
MAIS à bien y réfléchir je pense que ton idée est préférable à la mienne: pour des raisons de sécurité comme tu l'évoques, et également parce-que cette notion de dépassement peut effectivement être une valeur du modèle (que tu as nommée: isBoutonDisabled, je l'aurais d'ailleurs plutôt appelée (côté modèle bien sûr): isMntMaxAtteint() (une méthode donc), ainsi la vue serait observatrice de cet état du modèle: BIEN VU, merci.
*************************************************

Finalement tristan_m, je pense que ta vision est préférable, enfin pour l'instant ( ) car il faut quand même voir avec le temps et éprouver cette façon de faire, ce que je ferai...

En effet, la façon dont la Vue procède pour signifier tel ou tel état du Modele, est sa spécificité, c'est elle qui choisit comment informer l'utilisateur de tel ou tel état du Modele (Griser un bouton, mettre en rouge, faire clignoter, rendre invisible, afficher tout simplement une valeur(Graphe, nombre, ...) ).


Je reste donc sur cette vision, que tu exposes tristan_m, car elle me semble plus orientée MVC et plus conforme au rôle de la Vue, en effet.

Pour le reste: rôle du Modele, et du coup rôle du Controleur, nos avis finissent par converger, bonne nouvelle...


Donc un grand merci à toi, cette nouvelle approche va beaucoup m'aider.
Et, me faire changer d'avis comme ça (avec arguments à l'appui), comme tu l'as fais, c'est pas rien, (j'suis assez têtu en général!)





Bon et bien j'espère que tout ceci apportera à d'autres,
et si vos opinions divergent de ce qui suit, merci d'intervenir :





CONCLUSION SUR LES ROLES:


- LE MODELE:

. Représenter et encapsuler les données d'une LOGIQUE METIER et offrir à l'extérieur des moyens de lire et d'en modifier certaines.


- LA VUE:

. Permettre à l'utilisateur d'avoir une représentation VISUELLE du
MODELE ou d'une partie du MODELE, la plus à jour possible.
En général, une VUE est spécifique à un MODELE donné.
(On peut en effet imaginer des Vues plus généralistes susceptibles
de pouvoir représenter plusieurs MODELES).

.Permettre à l'utilisateur d'interagir avec le MODELE
(Demandes de: modif, ajout, suppr, visu)

. On notera qu'il incombe TOTALEMENT à la Vue de choisir la façon dont elle veut signifier tel ou tel état du MODELE (Griser un bouton, mettre en rouge, faire clignoter, rendre invisible, afficher tout simplement une valeur(Graphe, nombre, ...) ). Cette logique d'affichage n'incombe pas au Contrôleur.



- LE CONTROLEUR:

. Recevoir les Demandes de l'utilisateur que lui transmet donc la VUE, les
interpréter vis-à-vis du MODELE, les filtrer, les contrôler.

. Demander au MODELE de se mettre à jour (modif, ajout, suppr).

.On peut éventuellement imaginer que parfois , le CONTROLEUR, et UNIQUEMENT pour son propre compte, c-à-d afin de bien remplir sa mission de filtrage et de contrôle, ait besoin d'aller lire directement certaines valeurs du MODELE.




Voilà j'espère être dans le vrai cette fois.


Merci pour vos futures critiques quelqu'elles soient!


Joyeuses fêtes à tous.

[rp37000]

Du coup :
On a un Diagramme de classes légèrement différent (en rouge et rose)
du premier que j'avais mis en pièce jointe plus haut.

[Patriarch24]

Juste pour préciser car il me semble que cela n'est pas clair dans les posts (que j'ai survolés) : jamais le contrôleur n'indique à la vue comment afficher un modèle, c'est uniquement de la responsabilité de la vue. Le contrôleur reçoit les requêtes, les transmet au modèle et ordonne à une (ou des) vues de s'afficher.

Quant au problème du bouton grisé, j'imagine que cela dépend de l'état interne du modèle (pattern Etat ou membre privé booléen généralement). Sinon il peut aussi s'agir d'un paramètre de l'application (je n'ai pas de bon exemple cependant, pour moi l'état du modèle est altéré).

[tristan_m]

Bonjour,

Effectivement Patriarch24, face à deux romanciers comme rp37000 et moi, je comprends que la discussion ne soit que survolée .
(Je n'arrive pas à faire des messages conçis... )
En tout cas, merci pour ton intervention, je crois qu'elle confirme le point qui a le plus fait débat et sur lequel nous sommes en train de converger, à savoir l'influence directe qu'a le contrôleur sur le contenu de la vue.

Je suis d'ailleurs bien content que nous arrivions finalement à une solution convergente, même si comme tu l'as dit rp37000, il faut voir à l'usage ce que ça donne.


Sinon je souhaitais rajouter un détail sur le point suivant :

.On peut éventuellement imaginer que parfois , le CONTROLEUR, et UNIQUEMENT pour son propre compte, c-à-d afin de bien remplir sa mission de filtrage et de contrôle, ait besoin d'aller lire directement certaines valeurs du MODELE.

Il est peut être possible de se passer de requête directe (du style modele.getValue()) grâce aux retours des fonctions. En effet, on peut imaginer que les fonctions du modèle retournent une valeur indiquant comment s'est passé le traitement de la fonction, et ainsi faire passer le contrôleur dans l'état correspondant approprié.

... Mais c'est vraiment un détail, et je ne sais pas si cela couvre tous les cas.

[rp37000]

Bonjour à tous,

Patriarch24, je te remercie de ton intervention, et prends en note ta remarque sur le fait qu'un autre rôle du Contrôleur est d'ordonner à une (ou des) vues de s'afficher.


Tristan_m, je te remercie également pour ta remarque, je comprends ce que tu veux dire, par exemple si le contrôleur fait:
this.modele.setPropertyX(xxx), il peut éventuellement faire un :
valRetour=this.modele.setPropertyX(xxx) et se servir ensuite de valRetour.
Cependant, je ne parlais pas de la même chose: je disais que parfois le Contrôleur peut avoir besoin d'aller lire (this.modele.getValue()) une valeur donnée du modele parce-que la décision qu'il a à prendre dépend de cette valeur.
Exemple: Le Contrôleur récupère une saisie de l'utilisateur sous sollicitation de la Vue, jusque là ok, mais on peut imaginer que le Contrôleur ait besoin d'une Autre info. pour Autoriser ou non la modif. du modele avec cette saisie, et cette info-ci: il ne pourrait par exemple l'avoir que dans le modele. (this.modele.getLInfo()).

//Suite à Validation d'une saisie dans la Vue, la métode suivante du //Contrôleur serait appelée:

valSaisieX = this.vue.getWidgetX_Value();//Récup.de la saisie par leContrôleur
if (this.modele.getLInfo()=="gggg" && valSaisieX>455)
{
this.modele.setPropertyX(valSaisieX); //Mise du modele à jour autorisée
}
else
{
//PAS DE MISE A JOUR DU MODELE
this.vue.setLibErrMsg("Saisie non autorisée....");
}

Est-ce-que je suis plus clair??

D'ailleurs vous remarquerez le
this.vue.setLibErrMsg("Saisie non autorisée...."); qui est une demande DIRECTE de MODIF. de la Vue par le CONTROLEUR? Qu'en pensez-vous?

[Patriarch24]

Cependant, je ne parlais pas de la même chose: je disais que parfois le Contrôleur peut avoir besoin d'aller lire (this.modele.getValue()) une valeur donnée du modele parce-que la décision qu'il a à prendre dépend de cette valeur.
Exemple: Le Contrôleur récupère une saisie de l'utilisateur sous sollicitation de la Vue, jusque là ok, mais on peut imaginer que le Contrôleur ait besoin d'une Autre info. pour Autoriser ou non la modif. du modele avec cette saisie, et cette info-ci: il ne pourrait par exemple l'avoir que dans le modele. (this.modele.getLInfo()).

Généralement, et pour découpler les contrôleurs de la couche métier, on délègue les services métiers à la couche métier, via une façade (voir les patterns J2EE Application Service, Session Facade, Business Delegate). Ce pattern est plus utilisé en J2EE (le contrôleur est une servlet, le service un EJB) mais peut se reporter dans les applications desktop. Le contrôleur n'a nul besoin d'avoir accès aux données métiers.
En résumé ça donne :
vue (event) -> controller (data) -> service -> modele
où service et modèle forment la couche métier. Les services sont des interfaces regroupant des fonctionnalités de service (service de gestion des clients par exemple).

[rp37000]

Ok Patriarch24,

Donc en général, le Contrôleur fait bêtement son
valRetour=this.modele.setPropertyX(xxx)
et c'est dans la couche métier qu'on va tester si il est possible de mettre à jour
le modèle et non pas dans le contrôleur?
Le contrôleur dans ce cas se servirait de la valeur valRetour pour savoir si la mise à jour a pu correctement s'effectuer?

Mais alors à quoi va servir le Contrôleur si ça n'est pas lui qui teste si oui ou non le modèle peut être mis à jour??
Parce-que pour moi le rôle du Contrôleur est justement de traduire mais aussi
FILTRER les demandes qui viennent de la Vue.

[hegros]

Donc en général, le Contrôleur fait bêtement son
valRetour=this.modele.setPropertyX(xxx)

et c'est dans la couche métier qu'on va tester si il est possible de mettre à jour
le modèle et non pas dans le contrôleur?
Le contrôleur dans ce cas se servirait de la valeur valRetour pour savoir si la mise à jour a pu correctement s'effectuer?

Il y a plusieurs controleurs en fait. IHM/Métiers/DAO en sont des exemples basiques.

On parle aussi d'un controleur par cas d'utilisation lorsqu'on modèlise avec UML, j'avoue cela ne change rien au fait que cela reste du MVC.


Je dirais que le controleur IHM fait bêtement

Code :

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

this.ControleurMetier.setPropertyX(xxx);

Mais alors à quoi va servir le Contrôleur si ça n'est pas lui qui teste si oui ou non le modèle peut être mis à jour??

Le contrôleur IHM fait 2 choses soit il demande à la vue de se mettre à jour par exemple je coche une case à cocher sur l'ihm et le controleur va demander à la vue de changer sa couleur de fond soit il délégue au controleur métiers lorsqu'il s'agit d'action sensé modifier le modèle.

Pour reprendre tes mots : pour savoir si le modèle doit être mis à jour c'est probablement une classe RegleDeGestion dans la couche métiers qui va tester si oui ou non le modèle peut-être mis à jour.

[rp37000]

Bonjour hegros,


Oula ça commence à chauffer, nous voilà avec 2 voire 3 contrôleurs!


Si j'ai bien compris tu qualifies de Contrôleur IHM, celui "habituel"...
A ce propos, on notera que le changement de couleur de la Vue dont tu parles, qui est ordonné par le contrôleur IHM est légitime dans l'exemple que tu donnes, car cet état (la couleur) ne réflète pas l'état du modèle mais bien celui de la Vue. (Je veux dire que sinon la Vue serait allée interroger le modèle pour savoir si elle devait, elle-même se faire changer de couleur).
Le Contrôleur IHM sert donc à la fois (dans CERTAINS cas) à modifier certaines caractéristiques de la Vue(des caractéristiques ne reflétant pas le Modèle mais la Vue),
et à la fois à traduire les demandes que l'utilisateur fait sur la Vue,
en action sur le modèle.
Tristan_m, la remarque en italique ci-dessus devrait t'intéresser (le fait que le Contrôleur ordonne à la Vue de se modifier... c'est un contre-exemple de ce sur quoi on s'était mis d'accord mais bon je trouve ça justifié dans ce cas là.)



hegros, ce que tu appelles Contrôleur Métier, c'est celui que tu insères entre le Contrôleur IHM et le modèle, c'est ça?
Et qui va donc vérifier, filtrer les demandes de mise à jour du modéle issues du Contrôleur IHM?


Enfin, le Contrôleur DAO, se situerait entre la Base de Données et les classes
du modele susceptibles d'accéder aux données de cette Base?

Ai-je bien compris?


Merci pour ces éclaircissements hegros.

[hegros]

Oula ça commence à chauffer, nous voilà avec 2 voire 3 contrôleurs!

Oui même beaucoup beaucoup plus je t'ai parlé d'un controleur par UC de même tu peux avoir plusieurs controleurs d'ihm.

Si j'ai bien compris tu qualifies de Contrôleur IHM, celui "habituel"...

Il n'y a pas de Controleur habituel....Il y a un controleur IHM, un controleur métiers etc...

ce que tu appelles Contrôleur Métier, c'est celui que tu insères entre le Contrôleur IHM et le modèle, c'est ça?

oui.


[quote]Et qui va donc vérifier, filtrer les demandes de mise à jour du modéle issues du Contrôleur IHM?[/B]

Le controleur IHM délégue le boulot au controleur métiers c'est ce dernier qui gérera les mises à jour du modèle et qui filtrera les demandes. Le controleur IHM il reste à sa place cela n'est pas son boulot de vérifier des règles métiers.

[rp37000]

D'accord hegros,

Merci pour ces précisions.

[hegros]

je voulais mettre un diagramme de classe pour visualiser le machin voilà c'est fait

[rp37000]

Oui d'accord hegros, merci.

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