Discussion :

[Hephaistos007]

Je suis tombé tout bêtement sur cette remarque accessible sur le site officiel de struts :

The term "MVC" originated with the SmallTalk Model-View-Controller framework. In Smalltalk MVC, the View updates itself from the Model, via the "Observer" pattern. The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.

But, a direct link between the Model and the View is not practical for web applications, and we modify the classic MVC arrangement so that it would look less like a loop and more like a horseshoe with the controller in the middle.

[Patriarch24]

Le problème comme le dit Hephaistos007 c'est que MVC est un terme devenu plus ou moins générique pour désigner un ensemble de modèles différents (MVC, Document-Vue, MVP, MVPM, ...). Il existe énormément de stratégies différentes, appelées MVC par abus de langage.
De fait, il n'existe pas un "MVC idéal", mais le modèle MVC, et les autres. Avec des stratégies différentes (Vue Passive, Contrôleur de Supervision, etc.).

Pour plus d'infos : http://martinfowler.com/eaaDev/ dans la section "Presentation Patterns".

[tse_jc]

Bonjour,

Permettez-moi d'apportez ma pierre à l'édifice.

Déjà le développement web n'est rien d'autre qu'un environnement client serveur en réseau avec un serveur tiers : Client - serveur tiers - DB. C'est minimaliste mais c'est une architecture qui ne s'étends donc pas au simple environnement web.

Elle reste particulière car elle impose des contraintes techniques supplémentaires influant directement les performances d'une application développée pour une telle structure d'environnement. Donc appliquer un pattern (ou version de pattern) incompatible ou non optimisé pour un tel environnement juste pour le principe de montrer qu'on sait le faire n'a aucun sens ni aucun intérêt.
C'est un peu comme si on concevait une voiture pour une utilisation autre que celle dont on a besoin.

Et pour finir, 3° point, si le MVC est difficilement applicable au client/serveur (sans communication bidirectionnelle), il peut exister à différents niveaux.

Je reste un peu dubitatif sur cette phrase. Si c'est au sens réseau, une communication non bidirectionnelle n'a pas de sens. Si c'est au niveau applicatif, si le contrôleur interroge le modèle ou donne un ordre au modèle en principe il y a toujours une réponse, elle est donc à ce titre toujours bidirectionnelle. S'il s'agit que le contrôleur reçoive un ordre du modèle (au sens du push serveur évoqué dans la réponse), je me permet de rappeler que dans un tel contexte "web" le contrôleur n'a pas d'ordre à recevoir du modèle, car c'est son rôle d'en donner et de contrôler les flux. L'utilisateur peut le requêter à travers la vue ou à travers le front controller. D'où le modèle évoqué du MVC2 adapté à cet environnement et dans lequel le contrôleur joue un rôle central pour rester efficace et performant. Donc en fonction de la réponse du modèle à un ordre du controller, le controller saura quelle mesure adopter pour respecter les contraintes et la logique métier applicative et s'il doit par exemple plutôt laisser la décision à l'utilisateur.

Ensuite pour la question de faire communiquer la vue et le contrôleur via une gestion évènementielle afin de coupler faiblement la vue du contrôleur, sauf à mettre le client sur le serveur, cela est sans intérêt est contre performant et productif en client serveur web. Donc à partir du moment où le client devient distant du serveur, afin d'optimiser les échanges et la bande passante la vue doit être en mesure d'évaluer la nécessite d'interroger le controller et savoir précisément qui et comment interroger sur le serveur pour faire son travail. La vue et le contrôleur doivent donc être fortement liés pour être efficaces. Le getview() sur le contrôleur est légitime car c'est à lui d'instancier la vue pour la fournir au client si il est nécéssaire de le faire pour éviter de surcharger le réseau, et lui seul à les outils pour en juger.

En ce qui concerne instancier un contrôleur à partir d'une vue pour gérer une vue partielle, tout dépends le contexte, mais dans un contexte "dev web" faut arrêter un peu et rester raisonnable quand à la granularité de la gestion objet appliquée à la vue. Si on va par là où doit-on mettre la limite et à quel titre? doit-on mettre un contrôleur derrière chaque caractère d'une phrase pour en gérer sa vue? ça n'a pas de sens. Une vue doit se limiter à une fenêtre applicative (sans instanciation de contrôleur partiel) et bannir la fenêtre qui fait tout du style usine à gaz: faut se limiter aux contraintes métier et s'y tenir et savoir adapter les besoins applicatifs à l'environnement d'utilisation au niveau maîtrise d'ouvrage.

Voilà ++

[tse_jc]

Bonjour,

Je vais compléter ma réponse car elle peut paraître incomplète voir inexacte en certains endroits.
En MVC dans un contexte "web" pour garder un langage vulgarisé et le même que celui abordé dans le post initial, il faut bien comprendre que le cahier des charges initial est d'optimiser la bande passante (on ne requête sur le réseau lorsque cela est absolument nécessaire) tant en quantité de requête qu'en contenu. Cela permet entre autre choses d'augmenter la capacité de charge et de gestion concurrentielle de l'applicatif, donc cela reste un minimum syndical si je puis dire.

Dans ce contexte ce n'est pas au contrôleur central de gérer la vue qu'il a instancié (attention: à ne pas prendre au sens objet du terme) car cela n'est pas son rôle. Par contre il fournit au client le contrôleur de la vue qui lui est associé (gestion interaction IHM au niveau client), généralement développé en Javascript dans le contexte évoqué initialement. On peut donc dire que c'est le contrôleur de la vue situé au niveau client qui va dialoguer avec le contrôleur central et non la vue directement.
Dans cet architecture, le serveur ne peut faire confiance à ce qui provient du client, il est donc déraisonnable de faire communiquer le modèle et la vue directement ne serait-ce qu'en lecture seule. C'est le travail primaire du contrôleur central de vérifier la légitimité, l'intégrité et le contenu des requêtes qu'il reçoit afin de les transmettre au modèle. C'est un impératif qui oblige au niveau du modèle.

Bon week-end à tous.

Jc.