Y a-t-il une différence entre le modèle standard "Modèle-Vue-Contrôleur" et le modèle "Modèle-Vue-Vue-Modèle" de Microsoft ?
Les deux modèles apparaissent, de manière différente, dans le développement ASP.Net et Silverlight/WPF.
Pour ASP.Net, MVVM est utilisé pour reliure à double sens les données dans les vues. Il s'agit généralement d'une mise en œuvre côté client (par exemple, à l'aide de Knockout.js). MVC, quant à lui, est un moyen de séparer les préoccupations. du côté du serveur .
Pour Silverlight et WPF, le modèle MVVM est plus englobant et peut apparaître pour remplacer le MVC (ou d'autres modèles d'organisation des logiciels en responsabilités distinctes). Une hypothèse, qui ressortait fréquemment de ce modèle, était que le modèle ViewModel a simplement remplacé le contrôleur dans MVC (comme si vous pouviez simplement remplacer VM pour C dans l'acronyme et tout serait pardonné)...
Le problème est le suivant : pour être testable indépendamment*, et surtout réutilisable en cas de besoin, un modèle de vue n'a aucune idée de la vue qui l'affiche, mais plus important encore aucune idée de l'origine de ses données .
*Remarque : dans la pratique, les contrôleurs suppriment la plupart de la logique du ViewModel, qui nécessite des tests unitaires. La VM devient alors un conteneur muet qui nécessite peu, voire pas, de tests. C'est une bonne chose car la VM n'est qu'un pont entre le concepteur et le codeur, et doit donc rester simple.
Même en MVVM, les contrôleurs contiennent généralement toute la logique de traitement et décident quelles données afficher dans quelles vues en utilisant quels modèles de vues.
D'après ce que nous avons vu jusqu'à présent, le principal avantage du modèle ViewModel est de supprimer le code du code-behind XAML. pour faire de l'édition de XAML une tâche plus indépendante . Nous créons toujours des contrôleurs, au fur et à mesure des besoins, pour contrôler (sans mauvais jeu de mots) la logique globale de nos applications.
Nous avons également noté que le Cadre de génération de code Sculpture met en œuvre MVVM et un modèle similaire à Prism ET il fait également un usage intensif des contrôleurs pour séparer toute la logique des cas d'utilisation.
J'ai ouvert un blog sur ce sujet que je compléterai au fur et à mesure (archives uniquement car l'hébergement a été perdu). . La combinaison de MVCVM avec les systèmes de navigation courants pose des problèmes, car la plupart des systèmes de navigation n'utilisent que des vues et des VM, mais j'y reviendrai dans des articles ultérieurs.
L'utilisation d'un modèle MVCVM présente un avantage supplémentaire. Seuls les objets du contrôleur doivent exister en mémoire pendant toute la durée de vie de l'application. et les contrôleurs contiennent principalement du code et peu de données d'état (c'est-à-dire une surcharge de mémoire minime). Cela donne des applications beaucoup moins gourmandes en mémoire que les solutions où les modèles de vue doivent être conservés et c'est idéal pour certains types de développement mobile (par exemple Windows Mobile utilisant Silverlight/Prism/MEF). Cela dépend bien sûr du type d'application, car vous pouvez toujours avoir besoin de conserver les VMs en cache occasionnelles pour la réactivité.
Note : Ce post a été modifié de nombreuses fois, et ne ciblait pas spécifiquement la question étroite posée, j'ai donc mis à jour la première partie pour couvrir cela aussi. Une grande partie de la discussion, dans les commentaires ci-dessous, ne concerne que l'ASP.Net et non l'image plus large. Ce billet avait pour but de couvrir l'utilisation plus large de MVVM dans Silverlight, WPF et ASP.Net et d'essayer de décourager les gens de remplacer les contrôleurs par des ViewModels.
@Tomasz Zielinski : C'est vrai, mais "où ils sont utilisés" n'était pas la question (ou le point de ma réponse). Mon point de vue est que les contrôleurs sont toujours utiles dans MVVM.
Je suis d'accord. Mon commentaire a été provoqué par une illumination soudaine et non parce que je n'étais pas d'accord avec vous.
Nous avons également utilisé des contrôleurs pour contrôler le "flux" des vues dans une interface utilisateur de type assistant.
Je pense que le moyen le plus simple de comprendre ce que ces acronymes sont censés signifier est de les oublier pendant un moment. Pensez plutôt aux logiciels dont ils sont issus, chacun d'entre eux. Cela se résume en fait à la différence entre les débuts du web et le bureau.
Au milieu des années 2000, alors que leur complexité augmentait, le modèle de conception MVC, décrit pour la première fois dans les années 1970, a commencé à être appliqué aux applications web. Pensez à la base de données, aux pages HTML et au code entre les deux. Affinons un peu ce modèle pour arriver au MVC : pour la "base de données", supposons la base de données plus le code d'interface. Pour les "pages HTML", supposons des modèles HTML et du code de traitement des modèles. Pour le "code intermédiaire", supposons que le code associe les clics de l'utilisateur à des actions, affectant éventuellement la base de données et provoquant certainement l'affichage d'une autre vue. C'est tout, du moins dans le cadre de cette comparaison.
Retenons une caractéristique de ce matériel web, non pas telle qu'elle est aujourd'hui, mais telle qu'elle existait il y a dix ans, lorsque JavaScript était une nuisance méprisable et de bas étage, dont les vrais programmeurs faisaient bien de se tenir à l'écart : La page HTML est essentiellement muette et passive. Le navigateur est un client léger, ou si vous voulez, un client pauvre. Il n'y a pas d'intelligence dans le navigateur. Le rechargement complet de la page est la règle. La "vue" est générée à nouveau à chaque fois.
Rappelons que cette façon de faire du web, bien que faisant fureur, était horriblement arriérée par rapport au bureau. Les applications de bureau sont des clients lourds, ou des clients riches, si vous voulez. (Même un programme comme Microsoft Word peut être considéré comme une sorte de client, un client pour les documents). Ce sont des clients pleins d'intelligence, pleins de connaissances sur leurs données. Ils ont de l'état. Ils mettent en cache les données qu'ils manipulent en mémoire. Il n'y a pas de conneries comme le rechargement complet d'une page.
Et c'est probablement de cette manière de faire du bureau riche qu'est né le deuxième acronyme, MVVM. Ne vous laissez pas tromper par les lettres, par l'omission du C. Les contrôleurs sont toujours là. Ils doivent l'être. Rien n'est supprimé. Nous ajoutons simplement une chose : l'état, les données mises en cache sur le client (et avec cela l'intelligence pour gérer ces données). Ces données, essentiellement un cache sur le client, sont maintenant appelées "ViewModel". C'est ce qui permet une interactivité riche. Et c'est tout.
Nous pouvons constater qu'avec Flash, Silverlight et - surtout - JavaScript, le web a adopté le MVVM. Les navigateurs ne peuvent plus être légitimement qualifiés de clients légers. Regardez leur programmabilité. Regardez leur consommation de mémoire. Regardez toute l'interactivité Javascript sur les pages Web modernes.
Personnellement, je trouve cette théorie et cet acronyme plus faciles à comprendre en regardant ce à quoi ils se réfèrent dans la réalité concrète. Les concepts abstraits sont utiles, surtout lorsqu'ils sont démontrés sur une matière concrète, de sorte que la compréhension peut boucler la boucle.
MVC n'a pas vu le jour sur le web. Trygve Reenskaug a introduit MVC dans Smalltalk-76 dans les années 1970.
Même s'il était changé en "MVC a été popularisé par la conception d'applications web". Je dirais que c'est de la spéculation sans citation appropriée.
Arialdo : Merci, je ne connaissais pas Smalltalk-76. (Je jouais avec d'autres jouets à l'époque. :) Blague à part, c'est intéressant de voir à quel point certains de ces concepts sont vieux. - @Dan, ce que j'ai écrit est : "[MVC] était peut-être là avant [le web], mais c'est le web qui l'a popularisé auprès des masses de développeurs web." Je pense toujours que c'est correct. Je n'ai pas de citation pour cela, mais je ne pense pas en avoir besoin, car cette popularisation massive de MVC fait partie de mon expérience personnelle lorsque j'ai commencé à travailler comme développeur web au début de la dernière décennie. Apache Struts était en vogue à l'époque, avec de nombreux beans pour MVC.
MVVM Modèle-Vue ViewModel est similaire à MVC, Contrôleur Modèle-Vue
Le contrôleur est remplacé par un ViewModel . Le ViewModel se trouve sous la couche d'interface utilisateur. Le ViewModel expose les données et les objets de commande dont la vue a besoin. On pourrait le considérer comme un objet conteneur dans lequel la vue va chercher ses données et ses actions. Le ViewModel tire ses données du modèle.
Russel East fait un blog discutant plus en détail Pourquoi MVVM est différent de MVC
La phrase "Le contrôleur est remplacé par un View Model" n'est pas correcte. Dans MVVM ce qui fait le rôle du contrôleur est le databinding (ou binding par convention si vous utilisez cela).
MVVM n'a de sens que si l'on utilise la liaison de données bidirectionnelle de WPF. Sinon, MVC/MVP etc. serait suffisant.
D'une part, MVVM est une évolution du modèle MVC qui utilise XAML pour gérer l'affichage. Cet article souligne certaines des facettes des deux.
L'idée maîtresse de l'architecture Modèle/Vue/ViewModèle semble être qu'au-dessus des données ("le Modèle"), il y a une autre couche de composants non visuels ("le ViewModèle") qui fait correspondre plus étroitement les concepts des données aux concepts de la vue des données ("la Vue"). C'est au ViewModel que la vue se lie, et non au modèle directement.
Je pense que le paragraphe que vous avez cité résume bien la situation. Un aspect du ViewModel est qu'il s'agit d'une version aplatie/altérée du modèle de la vue. De nombreux autres modèles MV* se lient au réel modèle.
"De nombreux autres modèles MV* se lient à nouveau au modèle réel" ? Vraiment ? Je pensais que la vue était toujours censée se lier au contrôleur dans MVC, quoi qu'il arrive.
Nocturne : Dans le MVC classique, la vue n'a pas grand chose à voir avec le contrôleur, elle se lie surtout au modèle. Pensez-y comme à un robot - Model représente la position des articulations du robot, View est un écran LCD sur lequel vous voyez le robot, Controller est par exemple un clavier. Dans une telle configuration, la vue dépend du modèle, c'est-à-dire que la position spatiale du robot, que vous pouvez voir sur l'écran, est une représentation directe du modèle.
Je pensais que l'une des principales différences était qu'en MVC, votre V lit directement votre M, et passe par le C pour manipuler les données, alors qu'en MVVM, votre VM agit comme un proxy M, tout en fournissant la fonctionnalité disponible à votre V.
Si je ne dis pas de bêtises, je suis surpris que personne n'ait créé un hybride, où votre VM n'est qu'un proxy M, et C fournit toutes les fonctionnalités.
+1. Le terme est correct, je pense. Mais pour ce qui est de créer un hybride M-MProxy-V-C, n'est-ce pas trop de séparation ? Je pense qu'il suffirait d'utiliser M-V-C alors que M est un modèle avec un support complet de Binding ;)
+1. Comme je l'ai dit plus haut, je pense que MVC est utilisé pour architecturer l'ensemble de l'application (web), tandis que MVVM est utilisé à l'intérieur du composant View de MVC.
@ktutnik : Le modèle se trouve généralement sur le serveur, alors que ViewModel vit sur le client. Il n'est donc pas possible pour HTML de se lier directement au modèle côté serveur. Par conséquent, nous avons besoin de ModelView qui agit comme un ensemble de travail local, non sauvegardé, de données extraites du modèle en utilisant par exemple AJAX/JSON.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
82 votes
Notez que si MVVM a été inventé par Microsoft, de nombreux développeurs et projets non-Microsoft ont commencé à adopter ce modèle. Ce commentaire vous a été apporté par le département "spite-the-MS-haters".
3 votes
Ayant travaillé avec MVVM pendant longtemps, ma première expérience avec MVC a été frustrante, jusqu'à ce que j'apprenne que je pouvais faire passer des ViewModels dans les deux sens au navigateur en utilisant les techniques de liaison trouvées dans MVVM. Mais comme Joel l'a dit plus haut, la seule façon de récupérer l'état du navigateur est d'afficher les changements dans un formulaire (qui utilise des paires nom/valeur). Si vous ne comprenez pas bien ce point. Vous aurez du mal avec MVC. Considérez simplement le contrôleur comme un injecteur de dépendances pour la vue et vous serez prêt.
6 votes
Une question aussi votée sur les [design patterns] de haut niveau. J'aimerais suggérer l'utilisation de diagrammes dans les réponses.
1 votes
Il faut également reformuler la question pour refléter le fait que la question est posée dans le contexte des technologies Microsoft... bien que la réponse acceptée ne le soit pas.
5 votes
Voici une version archivée de l'article de Joel : web.archive.org/web/20150219153055/http://joel.inpointform.net/
4 votes
Contrairement à la méthode MVC, le ViewModel n'est pas un contrôleur. Il agit plutôt comme un liant qui lie les données entre la vue et le modèle. Alors que le format MVC est spécifiquement conçu pour créer une séparation des préoccupations entre le modèle et la vue, le format MVVM avec liaison des données est conçu spécifiquement pour permettre à la vue et au modèle de communiquer directement entre eux. hackernoon.com/
0 votes
Exemples de code de Design Patterns dans différents langages : C#, C++, Go, Java, JavaScript, Python et Swift.