Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)

-- edit 2012-09-15 -- Le titre est changé de « Modèle‑Vue‑Contrôleur sur Client‑Serveur (questions) » en « Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC) », vu la tournure plus généraliste que prend le sujet malgré qu’il ait été ouvert sur une question spécifique. -- fin edit --

Le design Modèle‑Vue‑Contrôleur est simple à mettre en oeuvre dans une application native, où la communication entre les parties est directe.

Mais dans un Modèle‑Vue‑Contrôleur lui‑même dans un environnement Client‑Serveur, la communication n’est pas directe et devient un aspect auquel il faut penser tout le temps.

Dans cet environnement, il semble évident que le Modèle sera sur le Serveur et que la Vue sur le Client. Pour le contrôleur c’est plus ambigüe. S’il est assez simple, il peut résider sur le Client, à côté de la Vue. S’il est complexe, ce sera différent, mais normalement, il ne doit pas être trop complexe, et pourra alors, si on prend l’exemple du Web, être écrit dans un aussi mauvais langage (pas le choix) que l’est JavaScript.

Reste une chose qui me tracasse, qui est la communication quand le modèle est conséquent et que les actions du contrôleur sont fréquentes, ce qui est le cas typique d’un modèle éditable depuis la vue. Il est quasiment nécessaire d’avoir un modèle intermédiaire (ou un fragment de taille suffisante pour ne pas avoir à être synchroniser trop souvent), qui doit alors être sur la partie Client. Je n’aime pas ça, mais c’est évidemment inévitable si on ne veut pas avoir des problèmes de lenteur à cause des données émises vers et reçues du serveur trop fréquemment.

Seulement, où placer ce modèle intermédiaire ?

Personnellement, je l’associe au contrôleur. Mais je me demandais si des gens ont déjà étudié la question plus que je ne l’ai fait, et connaissent d’autres modèles qui peuvent être comparé entre eux.

Ou alors existent‑ils des gens qui font sans modèle intermédiaire ? Ça se passe comment avec Google Docs par exemple ?

Autre question : en terme de design, quel serait le mot le plus approprié pour désigner ce modèle intermédiaire ? Proxy ? Ce qui semble évident je crois, mais dans le doute, ce n’est pas plus mal de poser la question.

J’ai un peu abusé, le pattern MVC n’est quand‑même le plus indiqué dans tous les cas… mais ce n’était pas non‑plus la question ici, c’était celle du Model‑View‑Controller dans un contexte client‑serveur, comme sur le web, et voilà justement que je suis tombé sur une page qui en parle :

Interactive Application Architecture (aspiringcraftsman.com)

Il faut descendre en bas et aller à la section “The ModelView‑Controller Pattern for Web Applications”.


Dans l’article, JSP = Java Server Page.

On voit de tout quand on voit des schémas du modèle MVC, et j’en reparlerai peut‑être. Comme peu de schémas apportent quelque chose à la compréhension des différences entre les deux, d’en avoir vu un intéressant à l’instant me donne envie de le poster.

Il compare le MVC et le MVP (Model‑View‑Presenter)

Schéma N°1 (-- edit -- schéma partiellement erroné, voir plus loin -- fin edit --)


Image : blog.vuscode.com


Il est intéressant, parce qu’il fait bien apparaitre que :

• dans le pattern MVC, les événements utilisateur entrent par le contrôleur [1],
• dans le cas du MVP, ils entrent par la vue.

Et comme on voit souvent appeler MVC, des choses dans lesquels se sont les éléments de l’interface utilisateurs qui reçoivent et retransmettent les événements, on voir clairement que ce qui est souvent appelé MVC, n’est en fait pas du MVC, mais du MVP (ou une de ses variantes).

On voit également bien sur ce schéma, que dans le MVC, la vue n’est pas totalement dissociée du modèle. Erreur là encore, chez les gens qui disent appliquer le MVC parce qu’il sépare la vue du modèle. En fait ils n’appliquent pas la pattern MVC, mais le MVP, là aussi.

Lost in translations… il y a un problème de vocabulaire dans ce domaine, et le sigle MVC est utilisé à toutes les sauces, pour désigner ou qualifier n’importe quelle forme de triade comportant :

• un modèle ou abstraction,
• un contrôleur ou « présenteur »,
• une vue.

(et la présence de nombreux schémas erronés sur le Net, n’aide pas non‑plus)


[1]: Ce qui est confirmé par le schéma de collaboration sur la page de la version Anglaise de Wikipédia :

Schéma N°2


Image : en.wikipedia.org

Ce schéma dit que l’utilisateur voit la vue, et utilise le contrôleur; ce qui peut paraitre évident dans les termes, mais ne colle pas à la réalité des interfaces utilisateurs contemporaines, avec lesquelles les entrée utilisateurs se font dans la vue [2], même dans le cas d’entrée au clavier, les entrées allant à l’élément disposant du focus, et le focus étant lui même une notion dans l’interface utilisateur.


[2]: Oops, je voulais donner une référence qui le présente bien, mais j’ai perdu le lien. Je poste ça plus tard.

Je n’ai toujours pas retrouvé la référence que je voulais mettre en « [2] » plus haut, mais voici encore deux schémas, dont le premier est intéressant pour la petite variation qu’il présente à propos du MVC.


Schéma N°3 (-- edit -- schéma partiellement erroné, voir plus loin -- fin edit --)


Image : infragistics.com

Dans ce schéma d’un MVC, la liaison directe entre le Modèle et la Vue, est dans l’autre sens, elle part du Modèle et va vers la vue, alors qu’elle allait de la Vue vers le Modèle, dans le schéma du précédent message. Cela signifie que dans le schéma du précédent message, la Vue récupérait les données à présenter, auprès du Modèle, tandis que dans celui‑ci, c’est le Modèle qui envoi lui même les données à la Vue. Ça peut être acceptable, mais c’est une différence importante quand‑même, qui n’est pas légère : elle implique que dans le schéma ci‑dessus, le Modèle a une connaissance de la Vue, ce qui n’est pas un design des plus heureux, je crois. À moins qu’il ne s’agisse juste d’une erreur de la part de l’auteur…


La même page donne le schéma d’un MVP, qui est intéressant parce qu’il ajoute un détail, même s’il pourrait être omis dans le schéma et qu’il n’est pas obligatoire en pratique : une interface entre le Présentateur et la Vue. Ce détail fait que la Vue devient interchangeable, ou même qu’elle peut être déplacée dans un autre contexte, comme un environnement de tests dans lequel elle pourra être testée isolément et indépendamment de la triade.

Schéma N°4


Image : infragistics.com


P.S. J’ai changé le titre du topic, pour qu’il corresponde mieux à la tournure plus générale qu’a finalement pris l’abord du sujet.

Explication probable je crois : le schéma N°3 est mal dessiné, et la ligne pleine aurait dut être une ligne en pointillés, c’est‑à‑dire qu’au lieu d’une liaison directe, il s’agit probablement d’un événement émis par le Modèle, et auquel la Vue a souscrit. Après une telle correction appliquée au schéma ou à son interprétation, il devient plus clair.

Il reste cependant encore une erreur dans ce schéma (y compris dans le schéma N°1), mais j’attends un peu avant d’en dire plus.

L’erreur dont je parlais plus haut, est à propos des deux schémas de MCV, dans le schéma N°1 (sa partie du bas, celle du haut étant un MVP) et le schéma N°3 (tout le schéma).

Dans le MVC du schéma N°1, le Contrôleur a une liaison directe avec le Vue, et réciproquement, la Vue a une liaison directe avec le Contrôleur. Ceci n’est encore pas conforme au MVC d’origine (si on s’attache a garder leur sens aux termes, ce qui me semble nécessaire). Dans le MVC, le Contrôleur a une relation directe avec le Modèle, qu’il manipule ; la Vue, écoute les modification du Modèle, et se met à jour en conséquence.

Dans le MVC du schéma N°3, le Contrôleur reçois des événements de la Vue. Pourtant dans le MVC, cette relation n’existe pas. La réception d’événement de la Vue par le Contrôleur n’a aucun motif, et le schéma ne donne d’ailleurs pas de raisons.

Je posterai un schéma UML plus tard, mais pour l’instant et pour résumé : le MVC est à l’origine un modèle de SmallTalk (ce langage des années 1980/1990, basé sur l’envoie de messages). Martin Fowler, dans le lien plus bas, reprend l’étude du système d’origine pour recadrer la définition d’un MVC, sur des bases historiques. Dans le MVC, « le vrai », les relations sont comme suit :

• les entrées utilisateurs sont traitées par le Contrôleur, qui manipule le Modèle;
• le Modèle, quand il est modifié, envoie des événements de notifications auxquels la Vue a souscrit, et qu’elle interprète pour se mettre à jour;
• la vue récupère les données via une liaison directe avec le Modèle (les événements ne transmettent pas les données);
• le Contrôleur peut souscrire aux événements du Modèle, mais il n’est pas dit que ça lui soit vraiment utile.

Sans les détails, et juste pour résumer aux relations, on a donc :


(je poste un schéma UML plus tard)

À retenir pour correctement nommer les choses :




Lecture recommandée : GUI Architectures (martinfowler.com), par Martin Fowler. Il y explique l’architecture MVC de SmallTalk, en plus d’une autre architecture tellement commune qu’étrangement personne n’a ressenti le besoin de la nomer explicitement, et qu’il appel Formulaires et Contrôleurs (Forms and Controls). Il explique l’historique de la création du pattern MVP, créé pour résoudre les défaut du MVC, l’un de ces défaut étant que le MVC n’a pas d’objet ou de rôle où correctement placé la logique spécifique à la Vue et qui ne devrait pas normalement faire partie du Modèle. Dans le MVC, la Modèle peut être « pollués » par des choses qui n’appartiennent qu’à l’interface utilisateur, et donc bien qu’il y ait une séparation entre la Vue et le Modèle, l’interface utilisateur, elle, n’est pas totalement distincte du Modèle, sur lequel elle déteint.


Voir aussi son livre : Patterns of Enterprise Application Architecture, sur Amazon.fr (à droite, image de la couverture, pour le reconnaitre).

Voilà, un schéma édité avec Gaphor (gaphor.sourceforge.net) (pas terrible, buggé, mais y a pire que celui‑là) :

Schéma N°5

Le point commun à tous ces patterns qui sont parfois confondus entre eux, c’est la séparation entre le Modèle du Domaine (Domain Model) de l’application et l’interface utilisateur. Tous ces patterns, qu’ils collent ensemble le Contrôleur et la Vue ou au contraire qu’il les déconnecte totalement (genre, même pas de passage de message), ou toutes variations variations entre les deux, ont tous ce point commun.

Il n’en dit pas beaucoup sur ce point, mais le site de M. Fowler a une page sur cette question :

• Separated Presentation (martinfowler.com)

Le soulignement de ce point commun, devient ensuite une manière de souligner l’attention portée à tous ce qui se trouve de l’autre côté du Modèle du Domaine ; ce qui se trouve de l’autre côté pouvant d’ailleurs même comprendre un intermédiaire entre Modèle et Vue + Contrôleur, une interface intermédiaire qu’il appel la Couche de Service (Service Layer).

Il faut donc dans tous les cas, se représenter d’un côté un modèle abstrait et de l’autre côté, tous ce que l’on veut constituant l’interface, quelque soit le pattern qu’on utilise pour celle‑ci, avec un mûr entre les deux, qui ne peut être franchit que dans un sens : de l’interface vers l’Abstraction. L’introduction de ce mot, sera peut‑être l’occasion d’introduire plus tard un autre pattern, celui de Présentation‑Abstraction‑Contrôle, alias PAC. Mais avant cela, il faudra d’abord aborder le MVP, dont dérive le PAC. Le MVP n’a été présenté que brièvement, pas encore en détails. Pour bien le comprendre, il faudra présenter la manière dont‑il dérive et se distingue du MVC, qui lui a maintenant été assez présenté.


Schéma N°6



Un mûr franchissable dans un seul sens, isole le Modèle du Domaine et l’interface utilisateur, le premier étant isolé de la seconde, et la seconde ne dupliquant pas de choses du premier, à chacune de ses instances et variations.