Hello!

Inspiré(e) de prendre part à la discussion ? Ou de poser une question ou demander de l’aide ?

Alors bienvenues dans les grands sujets des forums de La Bulle : m’inscrire.

Cette partie du forum n’est pas compatible avec les bloqueurs publicitaires

Félicitations à vous, de préférer les accès payants plutôt que la gratuité par la publicité, c’est honnorable et cohérent de votre part. Malheureusement, l’accès payant par micropaiement (qui serait d’environ 1 cent pour 20 pages consultées) n’est pour l’instant pas encore mis en place, et l’accès gratuit sans publicité, est réservé aux membres actif(ve)s du forum. En attendant, si vous souhaitez poursuivre votre visite chez nous, vous pouvez ajouter le site à votre liste blanche, ou encore mieux, désactiver le bloqueur partout. Pour ajouter le site à votre liste blanche, pour Firefox (similaire pour les autres navigateurs), rendez‑vous en bas à gauche de la fenêtre de votre navigateur, et cliquez sur le menu comme dans l’exemple de l’image ci‑dessous, puis rechargez la page, en appuyant sur F5.

Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
Auteur Message
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Dim 5 Fév 2012 04:24
Message 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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Mer 5 Sep 2012 09:40
Message Re: Modèle‑Vue‑Contrôleur sur Client‑Serveur (questions)
Hibou a écrit : 
Le design Modèle‑Vue‑Contrôleur est simple à mettre en oeuvre dans une application native, où la communication entre les parties est directe.

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”.

Le lien a écrit : 
The first draft of the JSP specification included guidance for two approaches to using the new technology. The first was effectively a Model-View separation where requests were routed directly to JSPs which would in turn interact with the application’s model ("JavaBeans" in Java parlance). The second approach, recommended for more complex applications, was effectively a Model-View-Controller separation where requests were routed to Java Servlets which interacted with the model and subsequently transferred control to a JSP for rendering the view back to the browser. An updated draft of the JSP specification referred to these approaches as Model 1 and Model 2 respectively. While no association with the Smalltalk-80 MVC pattern was made within the specification, the similarity was noted in an article appearing in Java World magazine on December of the same year, stating that the Model 2 architecture could be seen as a "server-side implementation of the popular Model-View-Controller (MVC) design pattern".

Dans l’article, JSP = Java Server Page.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Ven 14 Sep 2012 12:21
Message Re: Modèle‑Vue‑Contrôleur sur Client‑Serveur (questions)
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
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
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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Sam 15 Sep 2012 01:33
Message Re: Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
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
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
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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Sam 15 Sep 2012 22:31
Message Re: Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
Hibou a écrit : 
Schéma N°3

[…]

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.

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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Dim 16 Sep 2012 15:06
Message Re: Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
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 :

Code : 

.

┌───────┐
Model
└─┬───┬─┘
┌───┘ └──┐
┌───┴──┐ ┌─────┴──────┐
View Controller
└──────┘ └────────────┘

(je poste un schéma UML plus tard)

À retenir pour correctement nommer les choses :

dans le MVC, il n’existe aucune forme de liaison entre la Vue et le Contrôleur !



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.

Image

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

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Dim 16 Sep 2012 15:26
Message Re: Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
Hibou a écrit : 
(je poste un schéma UML plus tard)


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

Schéma N°5

Image

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 18812
Dim 16 Sep 2012 20:08
Message Re: Modèle‑Vue‑Contrôleur et Modèle‑Vue‑Présentateur (et PAC)
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 :


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

Image

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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
cron