Quelle est la différence entre MVC et MVVM? [fermé]

Existe-t-il une différence entre le modèle standard "Model View Controller" et le modèle Microsoft / Model / View / ViewModel?

MVC / MVVM n'est pas un choix ni / ni .

Les deux modèles surgissent, de différentes manières, dans le développement ASP.Net et Silverlight / WPF.

Pour ASP.Net, MVVM est utilisé pour lier les données dans les deux sens dans les vues. Il s'agit généralement d'une implémentation côté client (par exemple en utilisant Knockout.js). MVC, d'autre part, est un moyen de séparer les problèmes côté serveur .

Pour Silverlight et WPF, le modèle MVVM est plus englobant et peut sembler remplacer le MVC (ou d'autres modèles d'organisation de logiciels dans des responsabilités distinctes). Une hypothèse, que , souvent , est sorti de ce modèle, était que le ViewModelsimplement remplacé le contrôleur MVC(comme si vous pouviez remplacer VMpour Cdans l'acronyme et tout serait pardonné) ...

Le ViewModel ne remplace pas nécessairement le besoin de contrôleurs séparés.

Le problème est que 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 surtout aucune idée d'où viennent ses données .

* Remarque: dans la pratique, les contrôleurs suppriment la plupart des logiques du ViewModel qui nécessitent des tests unitaires. La machine virtuelle devient alors un conteneur stupide qui nécessite peu ou pas de tests. C'est une bonne chose car la machine virtuelle n'est qu'un pont entre le concepteur et le codeur, elle doit donc rester simple.

Même dans MVVM, les contrôleurs contiennent généralement toute la logique de traitement et décident quelles données afficher dans quelles vues à l'aide de quels modèles de vue.

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 XAML derrière pour faire de l'édition XAML une tâche plus indépendante . Nous créons toujours des contrôleurs, au fur et à mesure des besoins, pour contrôler (sans jeu de mots) la logique globale de nos applications.

Les directives de base MVCVM que nous suivons sont:

• Les vues affichent une certaine forme de données . Ils n'ont aucune idée d'où viennent les données.
• Les ViewModels contiennent une certaine forme de données et de commandes , ils ne savent pas d'où proviennent les données ou le code ni comment elles sont affichées.
• Les modèles contiennent les données réelles (divers contextes, magasins ou autres méthodes)
• Les contrôleurs écoutent et publient les événements. Les contrôleurs fournissent la logique qui contrôle quelles données sont vues et où. Les contrôleurs fournissent le code de commande au ViewModel afin que le ViewModel soit réellement réutilisable.

Nous avons également noté que le cadre de code-gen de Sculpture implémente MVVM et un modèle similaire à Prism ET qu'il fait également un usage intensif des contrôleurs pour séparer toute la logique des cas d'utilisation.

Ne présumez pas que les contrôleurs sont rendus obsolètes par les modèles View.

J'ai commencé un blog sur ce sujet auquel je vais ajouter au fur et à mesure que je le pourrai . Il y a des problèmes avec la combinaison de MVCVM avec les systèmes de navigation courants, car la plupart des systèmes de navigation n'utilisent que des vues et des machines virtuelles, mais j'y reviendrai dans des articles ultérieurs.

Un avantage supplémentaire de l'utilisation d'un modèle MVCVM est que seuls les objets du contrôleur doivent exister en mémoire pendant toute la durée de vie de l'application et que les contrôleurs contiennent principalement du code et peu de données d'état (c'est-à-dire une petite surcharge de mémoire). Cela rend les applications beaucoup moins gourmandes en mémoire que les solutions où les modèles d'affichage doivent être conservés et il 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 devrez peut-être conserver les machines virtuelles mises en cache occasionnelles pour la réactivité.

Remarque: Ce message a été modifié de nombreuses fois et ne visait pas spécifiquement la question étroite posée, j'ai donc mis à jour la première partie pour couvrir maintenant cela également. Une grande partie de la discussion, dans les commentaires ci-dessous, se rapporte uniquement à ASP.Net et non à la vue d'ensemble. Ce message était destiné à couvrir l'utilisation plus large de MVVM dans Silverlight, WPF et ASP.Net et à décourager les gens de remplacer les contrôleurs par ViewModels.

Je pense que le moyen le plus simple de comprendre ce que ces acronymes sont censés signifier est de les oublier un instant. Pensez plutôt au logiciel avec lequel ils ont été créés, chacun d'eux. Cela se résume vraiment à la différence entre le début du Web et le bureau.

À mesure qu'ils grandissaient en complexité au milieu des années 2000, le modèle de conception de logiciel MVC - qui a été 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 cela un petit peu pour arriver à MVC: Pour »base de données«, supposons base de données plus code d'interface. Pour les »pages HTML«, supposons les modèles HTML plus le code de traitement des modèles. Pour le «code intermédiaire», supposons que le mappage de code des clics des utilisateurs sur les actions, affectant éventuellement la base de données, provoquant définitivement l'affichage d'une autre vue. C'est tout, au moins pour cette comparaison.

Gardons une caractéristique de ce truc sur le Web, pas telle qu'elle est aujourd'hui, mais telle qu'elle existait il y a dix ans, lorsque JavaScript était un ennui humble et méprisable, ce que les vrais programmeurs ont bien fait d'éviter: 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 aucune intelligence dans le navigateur. Règle de rechargement pleine page. La «vue» est de nouveau générée à chaque fois.

Souvenons-nous que cette méthode Web, malgré toute la rage, était horriblement en arrière par rapport au bureau. Les applications de bureau sont de gros clients 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 sont avec état. Ils mettent en cache les données qu'ils gèrent en mémoire. Pas de merde comme un rechargement de page entière.

Et cette riche façon de bureau est probablement à l'origine du deuxième acronyme, MVVM. Ne vous laissez pas berner par les lettres, par l'omission du C. Les contrôleurs sont toujours là. Ils doivent l'être. Rien n'est supprimé. Nous ajoutons juste une chose: l'état, les données mises en cache sur le client (et avec lui l'intelligence pour gérer ces données). Ces données, essentiellement un cache sur le client, s'appellent désormais »ViewModel«. C'est ce qui permet une riche interactivité. Et c'est tout.

• MVC = modèle, contrôleur, vue = communication essentiellement à sens unique = faible interactivité
• MVVM = modèle, contrôleur, cache, vue = communication bidirectionnelle = interactivité riche

Nous pouvons voir qu'avec Flash, Silverlight et - plus important encore - JavaScript, le Web a adopté MVVM. Les navigateurs ne peuvent plus être légitimement appelés 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 à quoi elle fait référence dans la réalité concrète. Les concepts abstraits sont utiles, en particulier lorsqu'ils sont démontrés sur une matière concrète, de sorte que la compréhension peut boucler la boucle.

MVVM Model-View ViewModel est similaire à MVC, Model-View Controller

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. Vous pouvez penser à cela comme un objet conteneur à partir duquel la vue obtient ses données et ses actions. Le ViewModel extrait ses données du modèle.

Russel East fait un blog discutant plus en détail Pourquoi MVVM est différent de MVC

D'une part, MVVM est une progression du modèle MVC qui utilise XAML pour gérer l'affichage. Cet article décrit certaines des facettes des deux.

L'idée maîtresse de l'architecture Model / View / ViewModel semble être qu'au-dessus des données («le modèle»), il y a une autre couche de composants non visuels («le ViewModel») qui cartographient les concepts des données de plus près. aux concepts de la vue des données ("la Vue"). C'est le ViewModel auquel la vue est liée, pas directement le modèle.

Microsoft a fourni une explication du modèle MVVM dans l'environnement Windows ici .

Voici une section cruciale:

Dans le modèle de conception Model-View-ViewModel, une application est composée de trois composants généraux.

• Modèle : cela représente le modèle de données consommé par votre application. Par exemple, dans une application de partage d'images, cette couche peut représenter l'ensemble des images disponibles sur un appareil et l'API utilisée pour lire et écrire dans la bibliothèque d'images.

• Affichage : une application est généralement composée de plusieurs pages d'interface utilisateur. Chaque page présentée à l'utilisateur est une vue dans la terminologie MVVM. La vue est le code XAML utilisé pour définir et styliser ce que l'utilisateur voit. Les données du modèle sont affichées pour l'utilisateur, et c'est le travail du ViewModel de nourrir l'interface utilisateur ces données en fonction de l'état actuel de l'application. Par exemple, dans une application de partage d'images, les vues seraient l'interface utilisateur qui montre à l'utilisateur la liste des albums sur l'appareil, les images d'un album et peut-être une autre qui montre à l'utilisateur une image particulière.

• ViewModel : le ViewModel lie le modèle de données, ou simplement le modèle, à l'interface utilisateur ou aux vues de l'application. Il contient la logique avec laquelle gérer les données du modèle et expose les données comme un ensemble de propriétés auxquelles l'interface XAML ou les vues peuvent se lier. Par exemple, dans une application de partage d'images, le ViewModel exposerait une liste d'albums et pour chaque album exposerait une liste d'images. L'interface utilisateur est indépendante de l'origine des images et de la façon dont elles sont récupérées. Il connaît simplement un ensemble d'images exposées par le ViewModel et les montre à l'utilisateur.

Je pensais que l'une des principales différences était que dans MVC, votre V lit votre M directement et passe par le C pour manipuler les données, tandis que dans MVVM, votre VM agit comme un proxy M, tout en vous fournissant les fonctionnalités disponibles V.

Si je ne suis pas plein d'ordure, je suis surpris que personne n'ait créé d'hybride, où votre machine virtuelle n'est qu'un proxy M et C fournit toutes les fonctionnalités.

MVC est un environnement contrôlé et MVVM est un environnement réactif.

Dans un environnement contrôlé, vous devriez avoir moins de code et une source de logique commune; qui devrait toujours vivre dans le contrôleur. Toutefois; dans le monde Web, MVC se divise facilement en logique de création de vue et en logique dynamique de vue. La création vit sur le serveur et la vie dynamique sur le client. Vous voyez beaucoup cela avec ASP.NET MVC combiné avec AngularJS alors que le serveur va créer une vue et passer un modèle et l'envoyer au client. Le client interagira ensuite avec la vue, auquel cas AngularJS intervient en tant que contrôleur local. Une fois soumis, le modèle ou un nouveau modèle est renvoyé au contrôleur de serveur et géré. (Ainsi, le cycle continue et il y a beaucoup d'autres traductions de cette manipulation lorsque vous travaillez avec des sockets ou AJAX, etc. mais dans l'ensemble, l'architecture est identique.)

MVVM est un environnement réactif, ce qui signifie que vous écrivez généralement du code (tel que des déclencheurs) qui s'activera en fonction d'un événement. En XAML, où MVVM prospère, tout cela est facile à faire avec le cadre de liaison de données intégré MAIS comme mentionné, cela fonctionnera sur n'importe quel système dans n'importe quelle vue avec n'importe quel langage de programmation. Ce n'est pas spécifique à MS. Le ViewModel se déclenche (généralement un événement de modification de propriété) et la vue y réagit en fonction des déclencheurs que vous créez. Cela peut devenir technique, mais l'essentiel est que la vue est sans état et sans logique. Il change simplement d'état en fonction des valeurs. De plus, les ViewModels sont sans état avec très peu de logique, et les modèles sont l'État avec une logique essentiellement nulle, car ils ne doivent conserver que l'état. Je le décris comme état d'application (modèle), traducteur d'état (ViewModel), puis état visuel / interaction (vue).

Dans un bureau MVC ou une application côté client, vous devez avoir un modèle et le modèle doit être utilisé par le contrôleur. En fonction du modèle, le contrôleur modifiera la vue. Les vues sont généralement liées aux contrôleurs avec interfaces afin que le contrôleur puisse fonctionner avec une variété de vues. Dans ASP.NET, la logique de MVC est légèrement en arrière sur le serveur car le contrôleur gère les modèles et transmet les modèles à une vue sélectionnée. La vue est ensuite remplie de données basées sur le modèle et possède sa propre logique (généralement un autre ensemble MVC tel que fait avec AngularJS). Les gens discuteront et confondront cela avec l'application MVC et essaieront de faire les deux à quel point le maintien du projet deviendra finalement une catastrophe. TOUJOURS mettre la logique et le contrôle en un seul endroit lors de l'utilisation de MVC. N'écrivez PAS la logique de la vue dans le code situé derrière la vue (ou dans la vue via JS pour le Web) pour prendre en compte les données du contrôleur ou du modèle. Laissez le contrôleur changer la vue. La seule logique qui devrait vivre dans une vue est tout ce qu'il faut pour créer et exécuter via l'interface qu'elle utilise. Un exemple de ceci est la soumission d'un nom d'utilisateur et d'un mot de passe. Qu'il s'agisse d'un bureau ou d'une page Web (sur le client), le contrôleur doit gérer le processus de soumission chaque fois que la vue déclenche l'action de soumission. Si cela est fait correctement, vous pouvez toujours trouver facilement votre chemin sur un site Web MVC ou une application locale. Qu'il s'agisse d'un bureau ou d'une page Web (sur le client), le contrôleur doit gérer le processus de soumission chaque fois que la vue déclenche l'action de soumission. Si cela est fait correctement, vous pouvez toujours trouver facilement votre chemin sur un site Web MVC ou une application locale. Qu'il s'agisse d'un bureau ou d'une page Web (sur le client), le contrôleur doit gérer le processus de soumission chaque fois que la vue déclenche l'action de soumission. Si cela est fait correctement, vous pouvez toujours trouver facilement votre chemin sur un site Web MVC ou une application locale.

MVVM est personnellement mon préféré car il est complètement réactif. Si un modèle change d'état, le ViewModel écoute et traduit cet état et c'est tout !!! La vue écoute ensuite le ViewModel pour un changement d'état et elle se met également à jour en fonction de la traduction du ViewModel. Certaines personnes l'appellent MVVM pur, mais il n'y en a vraiment qu'un et je me fiche de la façon dont vous le discutez et c'est toujours Pure MVVM où la vue ne contient absolument aucune logique.

Voici un petit exemple: disons que vous voulez avoir une diapositive de menu sur une pression de bouton. Dans MVC, vous aurez une action MenuPressed dans votre interface. Le contrôleur saura lorsque vous cliquez sur le bouton Menu, puis dites à la vue de glisser dans le menu en fonction d'une autre méthode d'interface telle que SlideMenuIn. Un aller-retour pour quelle raison? Si le contrôleur décide que vous ne pouvez pas ou ne voulez pas faire autre chose, c'est pourquoi. Le contrôleur devrait être en charge de la vue, la vue ne faisant rien à moins que le contrôleur ne le dise. TOUTEFOIS; dans MVVM, le menu des diapositives dans l'animation doit être intégré et générique et au lieu d'être invité à le faire, il le fera en fonction d'une certaine valeur. Il écoute donc le ViewModel et lorsque le ViewModel le dit, IsMenuActive = true (ou cependant) l'animation pour cela a lieu. Maintenant, avec cela dit, je veux faire un autre point VRAIMENT CLAIR et VEUILLEZ faire attention. IsMenuActive est probablement de mauvaise conception MVVM ou ViewModel. Lors de la conception d'un ViewModel, vous ne devez jamais supposer qu'une vue aura des fonctionnalités et passer simplement l'état du modèle traduit. De cette façon, si vous décidez de changer votre vue pour supprimer le menu et simplement afficher les données / options d'une autre manière, le ViewModel s'en fiche. Alors, comment géreriez-vous le menu? Quand les données ont du sens, c'est comme ça. Ainsi, une façon de le faire est de donner au menu une liste d'options (probablement un tableau de ViewModels internes). Si cette liste contient des données, le menu sait alors s'ouvrir via le déclencheur, sinon il sait se cacher via le déclencheur. Vous avez simplement des données pour le menu ou non dans le ViewModel. NE décidez PAS d'afficher / masquer ces données dans le ViewModel. traduire simplement l'état du modèle. De cette façon, la vue est complètement réactive et générique et peut être utilisée dans de nombreuses situations différentes.

Tout cela n'a probablement aucun sens si vous n'êtes pas déjà au moins un peu familier avec l'architecture de chacun et l'apprendre peut être très déroutant car vous trouverez ALOT OF BAD informations sur le net.

Donc ... des choses à garder à l'esprit pour bien faire les choses. Décidez à l'avance comment concevoir votre application et STICK TO IT.

Si vous faites MVC, ce qui est génial, assurez-vous que votre contrôleur est gérable et contrôle pleinement votre vue. Si vous avez une grande vue, pensez à ajouter des contrôles à la vue qui ont différents contrôleurs. JUSTE NE PAS cascader ces contrôleurs à différents contrôleurs. Très frustrant à entretenir. Prenez un moment et concevez les choses séparément d'une manière qui fonctionnera comme des composants séparés ... Et laissez toujours le contrôleur dire au modèle de valider ou de conserver le stockage. La configuration de dépendance idéale pour MVC dans est Afficher ← Contrôleur → Modèle ou avec ASP.NET (ne me lancez pas) Modèle ← Afficher ↔ Contrôleur → Modèle (où le modèle peut être le même ou un modèle totalement différent du contrôleur à la vue)... bien sûr, le seul besoin de connaître Controller in View à ce stade est principalement de faire référence aux points d'extrémité pour savoir où retourner un modèle.

Si vous faites MVVM, je bénis votre bonne âme, mais prenez le temps de le faire BIEN! N'utilisez pas d'interfaces pour un. Laissez votre vue décider de son apparence en fonction des valeurs. Jouez avec les données View with Mock. Si vous finissez par avoir une vue qui vous montre un menu (selon l'exemple) même si vous ne le vouliez pas à l'époque, alors BON. Votre vue fonctionne comme il se doit et réagit en fonction des valeurs comme il se doit. Ajoutez simplement quelques exigences supplémentaires à votre déclencheur pour vous assurer que cela ne se produit pas lorsque le ViewModel est dans un état traduit particulier ou commandez au ViewModel de vider cet état. Dans votre ViewModel, ne supprimez PAS cela avec une logique interne, comme si vous décidiez à partir de là si la vue devrait le voir ou non. N'oubliez pas que vous ne pouvez pas supposer qu'il existe ou non un menu dans le ViewModel. Et enfin, le modèle devrait simplement vous permettre de changer et probablement de stocker l'état. C'est là que la validation et tout se produira; par exemple, si le modèle ne peut pas modifier l'état, il se signalera simplement comme sale ou quelque chose. Lorsque le ViewModel s'en rend compte, il traduira ce qui est sale, et le View s'en rendra compte et affichera des informations via un autre déclencheur. Toutes les données de la vue peuvent être liées au ViewModel, donc tout peut être dynamique uniquement le modèle et ViewModel n'a absolument aucune idée de la façon dont la vue réagira à la liaison. En fait, le modèle n'a aucune idée d'un ViewModel non plus. Lors de la configuration des dépendances, ils doivent pointer comme tel et uniquement comme tel Si vous modifiez l'état, il se signalera simplement comme sale ou quelque chose. Lorsque le ViewModel s'en rend compte, il traduira ce qui est sale, et le View s'en rendra compte et affichera des informations via un autre déclencheur. Toutes les données de la vue peuvent être liées au ViewModel, donc tout peut être dynamique uniquement le modèle et ViewModel n'a absolument aucune idée de la façon dont la vue réagira à la liaison. En fait, le modèle n'a aucune idée d'un ViewModel non plus. Lors de la configuration des dépendances, ils doivent pointer comme tel et uniquement comme tel Si vous modifiez l'état, il se signalera simplement comme sale ou quelque chose. Lorsque le ViewModel s'en rend compte, il traduira ce qui est sale, et le View s'en rendra compte et affichera des informations via un autre déclencheur. Toutes les données de la vue peuvent être liées au ViewModel, donc tout peut être dynamique uniquement le modèle et ViewModel n'a absolument aucune idée de la façon dont la vue réagira à la liaison. En fait, le modèle n'a aucune idée d'un ViewModel non plus. Lors de la configuration des dépendances, ils doivent pointer comme tel et uniquement comme tel Toutes les données de la vue peuvent être liées au ViewModel, donc tout peut être dynamique uniquement le modèle et ViewModel n'a absolument aucune idée de la façon dont la vue réagira à la liaison. En fait, le modèle n'a aucune idée d'un ViewModel non plus. Lors de la configuration des dépendances, ils doivent pointer comme tel et uniquement comme tel Toutes les données de la vue peuvent être liées au ViewModel, donc tout peut être dynamique uniquement le modèle et ViewModel n'a absolument aucune idée de la façon dont la vue réagira à la liaison. En fait, le modèle n'a aucune idée d'un ViewModel non plus. Lors de la configuration des dépendances, ils doivent pointer comme tel et uniquement comme telView → ViewModel → Model (et une note latérale ici ... et cela sera probablement argumenté aussi mais je m'en fiche ... NE PAS PASSER LE MODÈLE à la VUE sauf si ce MODÈLE est immuable; sinon, enveloppez-le avec un ViewModel approprié. La vue ne devrait pas voir de période de modèle. Je donne à un rat la démo que vous avez vue ou comment vous l'avez fait, c'est faux.)

Voici ma dernière astuce ... Regardez une application MVC bien conçue, mais très simple, et faites de même pour une application MVVM. L'un aura plus de contrôle avec une flexibilité limitée à zéro tandis que l'autre n'aura aucun contrôle et une flexibilité illimitée.

Un environnement contrôlé est bon pour gérer l'ensemble de l'application à partir d'un ensemble de contrôleurs ou (une seule source) tandis qu'un environnement réactif peut être divisé en référentiels distincts sans aucune idée de ce que fait le reste de l'application. Micro gestion vs gestion libre.

Si je ne vous ai pas assez confus, essayez de me contacter ... Cela ne me dérange pas de passer en revue cela en détail avec des illustrations et des exemples.

À la fin de la journée, nous sommes tous des programmeurs et avec cette anarchie vit en nous lors du codage ... Donc les règles seront brisées, les théories changeront, et tout cela finira par se laver les cochons ... Mais quand on travaille sur de grandes projets et sur de grandes équipes, cela aide vraiment à se mettre d'accord sur un modèle de conception et à le faire respecter. Un jour, les petites mesures supplémentaires prises au début deviendront des sauts et des limites d'épargne plus tard.

Différence simple: (Inspiré du cours Coursera AngularJS de Yaakov)

MVC (Model View Controller)

1. Modèles: les modèles contiennent des informations sur les données. N'appelle ni n'utilise Controller and View. Contient la logique métier et les façons de représenter les données. Certaines de ces données, sous une forme quelconque, peuvent être affichées dans la vue. Il peut également contenir une logique pour récupérer les données d'une source.
2. Contrôleur: sert de connexion entre la vue et le modèle. Afficher les appels Controller et Controller appelle le modèle. Il informe essentiellement le modèle et / ou la vue à modifier selon les besoins.
3. Voir: Traite avec la partie UI. Interagit avec l'utilisateur.

MVVM (Model View View Model)

ViewModel :

1. C'est la représentation de l'état de la vue.
2. Il contient les données affichées dans la vue.
3. Répond pour afficher les événements, autrement dit la logique de présentation.
4. Appelle d'autres fonctionnalités pour le traitement de la logique métier.
5. Ne demande jamais directement à la vue d'afficher quoi que ce soit.

MVVM est un raffinement (discutable) du modèle de modèle de présentation . Je dis discutable, car la seule différence réside dans la façon dont WPF offre la possibilité de faire la liaison de données et la gestion des commandes.

Le viewmodel est un modèle "abstrait" pour vos éléments d'interface utilisateur. Il doit vous permettre d'exécuter les commandes et les actions dans votre vue de manière non visuelle (par exemple pour le tester).

Si vous avez travaillé avec MVC, vous avez probablement trouvé utile de créer des objets de modèle pour refléter l'état de votre vue, par exemple, pour afficher et masquer une boîte de dialogue d'édition, etc. Dans ce cas, vous utilisez un modèle de vue.

Le modèle MVVM est simplement la généralisation de cette pratique à tous les éléments de l'interface utilisateur.

Et ce n'est pas un modèle Microsoft, ce qui s'ajoute, c'est que les liaisons de données WPF / Silverlight sont particulièrement bien adaptées pour fonctionner avec ce modèle. Mais rien ne vous empêche de l'utiliser avec des faces de serveur java, par exemple.

Les autres réponses pourraient ne pas être faciles à comprendre pour celui qui n'est pas très familier avec le sujet des modèles architecturaux. Quelqu'un qui est nouveau dans l'architecture des applications voudra peut-être savoir comment son choix peut affecter son application dans la pratique et ce qui se passe dans les communautés.

En essayant de faire la lumière sur ce qui précède, j'ai composé ce scénario impliquant MVVM, MVP et MVC. L'histoire commence par un utilisateur cliquant sur le bouton «TROUVER» dans une application de recherche de films…:

Utilisateur: cliquez sur…

Voir : Qui est-ce? [ MVVM | MVP | MVC ]

Utilisateur: je viens de cliquer sur le bouton de recherche…

Voir : Ok, attendez une seconde…. [ MVVM | MVP | MVC ]

( Vue appelant le ViewModel | Presenter | Controller …) [ MVVM | MVP | MVC ]

Voir : Hey ViewModel | Présentateur | Contrôleur , un Utilisateur vient de cliquer sur le bouton de recherche, que dois-je faire? [ MVVM | MVP | MVC ]

ViewModel | Présentateur | Manette : Hey View , y a-t-il un terme de recherche sur cette page? [ MVVM | MVP | MVC ]

Voir : Oui,… le voici… «piano» [ MVVM | MVP | MVC ]

—— C'est la différence la plus importante entre MVVM ET MVP | MVC ———

Présentateur : Merci Voir ,… en attendant je recherche le terme de recherche sur le modèle , veuillez lui montrer une barre de progression [ MVP | MVC ]

(Le présentateur | Le contrôleur appelle le modèle …) [ MVP | MVC ]

ViewController : Merci, je vais rechercher le terme de recherche sur le modèle mais je ne vous pas à jour directement. Au lieu de cela, je déclencherai des événements pour searchResultsListObservable s'il y a un résultat. Vous feriez donc mieux d'observer cela. [ MVVM ]

(Tout en observant tout déclencheur dans searchResultsListObservable, la vue pense qu'elle devrait afficher une barre de progression à l'utilisateur, car ViewModel ne lui en parlerait pas)

——————————————————————————————

ViewModel | Présentateur | Contrôleur : Hey Model , avez-vous une correspondance pour ce terme de recherche ?: “piano” [ MVVM | MVP | MVC ]

Modèle : Hey ViewModel | Présentateur | Contrôleur , laissez-moi vérifier… [ MVVM | MVP | MVC ]

(Le modèle fait une requête à la base de données de films…) [ MVVM | MVP |MVC ]

( Après un moment … )

———— C'est le point de divergence entre MVVM , MVP et MVC ————–

Modèle : J'ai trouvé une liste pour vous, ViewModel | Présentateur , le voici en JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [ MVVM | MVP ]

Modèle : Il y a un résultat disponible, contrôleur. J'ai créé une variable de champ dans mon instance et l'ai remplie avec le résultat. Son nom est «searchResultsList» [ MVC ]

(Le présentateur | Le contrôleur remercie le modèle et revient à la vue ) [ MVP | MVC ]

Présentateur : Merci d'avoir attendu View , j'ai trouvé une liste de résultats correspondants pour vous et les ai arrangés dans un format présentable: [“Piano Teacher 2001 ″,” Piano 1993 ”]. Veuillez également masquer la barre de progression maintenant [ MVP ]

Contrôleur : Merci d'avoir attendu View , j'ai demandé à Model votre requête de recherche. Il dit qu'il a trouvé une liste de résultats correspondants et les a stockés dans une variable nommée «searchResultsList» à l'intérieur de son instance. Vous pouvez l'obtenir à partir de là. Veuillez également masquer la barre de progression maintenant [ MVC ]

ViewModel : Tout observateur sur searchResultsListObservable sera informé qu'il existe une nouvelle liste au format présentable: [«Piano Teacher 2001 ″,» Piano 1993 »]. [ MVVM ]

View : Merci beaucoup Presenter [ MVP ]

Vue : Merci " Contrôleur " [ MVC ] (Maintenant, la Vue se questionne: Comment dois-je présenter les résultats que j'obtiens du Modèle à l'utilisateur? L'année de production du film doit-elle venir en premier ou en dernier…?)

Voir : Oh, il y a un nouveau déclencheur dans searchResultsListObservable…, bon, il y a une liste présentable, maintenant je n'ai plus qu'à l'afficher dans une liste. Je devrais également masquer la barre de progression maintenant que j'ai le résultat. [ MVVM ]

Si vous êtes intéressé, j'ai écrit une série d'articles ici , comparant MVVM, MVP et MVC en implémentant une application Android de recherche de films.

Injection de ViewModels fortement typés dans la vue à l'aide de MVC

1. Le contrôleur est chargé de renouveler le ViewModel et de l'injecter dans la vue. (pour obtenir des demandes)
2. Le ViewModel est le conteneur pour DataContext et l'état d'affichage tel que le dernier élément sélectionné, etc.
3. Le modèle contient des entités DB et est très proche du schéma DB, il effectue les requêtes et le filtrage. (J'aime EF et LINQ pour cela)
4. Le modèle doit également prendre en compte les référentiels et / ou la projection des résultats dans des types forts (EF a une excellente méthode ... EF.Database.Select (chaîne de requête, paramètres) pour un accès ADO direct pour injecter des requêtes et récupérer des types forts. est un argument lent. EF n'est PAS LENT !
5. Le ViewModel obtient les données et effectue les règles métier et la validation
6. Le contrôleur sur le dos appellera la méthode ViewModel Post et attendra les résultats.
7. Le contrôleur injectera le Viewmodel nouvellement mis à jour dans la vue. La vue utilise uniquement une liaison de type forte .
8. La vue restitue simplement les données et renvoie les événements au contrôleur. (voir exemples ci-dessous)
9. MVC intercepte la demande entrante et l'achemine vers le contrôleur approprié avec un type de données fort

Dans ce modèle, il n'y a plus de contact de niveau HTTP avec les objets de demande ou de réponse car la machine MVC de MSFT nous les cache.

Pour clarifier le point 6 ci-dessus (sur demande) ...

Supposons un ViewModel comme celui-ci:

public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

La méthode du contrôleur de la publication ressemblera à ceci (voir ci-dessous), notez que l'instance de mvm est automatiquement instanciée par les mécanismes de liaison MVC. Vous n'avez donc jamais à descendre dans la couche de chaîne de requête! Ceci est MVC instanciant le ViewModel pour vous en fonction des chaînes de requête!

[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}

Notez que pour que cette méthode d'action ci-dessus fonctionne comme vous le souhaitez, vous devez avoir défini un CTOR nul qui initialise les éléments non retournés dans la publication. La publication doit également publier des paires nom / valeur pour les éléments qui ont changé. S'il manque des paires nom / valeur, le moteur de liaison MVC fait ce qui est tout simplement rien! Si cela se produit, vous pourriez vous dire "Je perds des données sur les articles" ...

L'avantage de ce modèle est que le ViewModel fait tout le travail "d'encombrement" en s'interfaçant avec la logique Model / Buisness, le contrôleur est simplement un routeur de toutes sortes. C'est SOC en action.

MVVM ajoute le modèle de vue dans le mix. C'est important, car cela vous permet d'utiliser une grande partie de l'approche contraignante de WPF, sans mettre toutes ces pièces spécifiques à l'interface utilisateur dans votre modèle standard.

Je peux me tromper, mais je ne suis pas sûr que MVVM force vraiment le contrôleur dans le mix. Je trouve le concept plus conforme à: http://martinfowler.com/eaaDev/PresentationModel.html . Je pense que les gens choisissent de le combiner avec MVC, pas qu'il soit intégré dans le motif.

D'après ce que je peux dire, le MVVM correspond au MV de MVC - ce qui signifie que dans un modèle MVC traditionnel, le V ne communique pas directement avec le M. Dans la deuxième version de MVC, il existe un lien direct entre M et V. MVVM semble prendre toutes les tâches liées aux communications M et V, et les coupler pour les découpler du C.En effet, il y a toujours le flux de travail d'application de plus grande portée (ou implémentation des scénarios d'utilisation) qui n'est pas entièrement pris en compte dans MVVM. C'est le rôle du contrôleur. En supprimant ces aspects de niveau inférieur des contrôleurs, ils sont plus propres et facilitent la modification du scénario d'utilisation de l'application et de la logique métier, ce qui rend également les contrôleurs plus réutilisables.

Cela me surprend que ce soit une réponse très votée sans mentionner l' origine de MVVM. MVVM est un terme populaire utilisé dans la communauté Microsoft et provient du modèle de présentation de Martin Fowler . Donc, pour comprendre le motif du motif et les différences avec les autres, l'article original sur le motif est la première chose à lire.

Eh bien, généralement MVC est utilisé dans le développement Web et MVVM est le plus populaire dans le développement WPF / Silverlight. Cependant, parfois l'architecture Web peut avoir un mélange de MVC et de MVVM.

Par exemple: vous pouvez utiliser knockout.js et dans ce cas, vous aurez MVVM du côté client. Et le côté serveur de votre MVC peut également changer. Dans les applications complexes, personne n'utilise le modèle pur. Il pourrait être judicieux d'utiliser un ViewModel en tant que «modèle» de MVC et votre véritable modèle fera essentiellement partie de cette machine virtuelle. Cela vous donne une couche d'abstraction supplémentaire.

MVVMC, ou peut-être MVC +, semble être une approche viable pour l'entreprise ainsi que pour le développement rapide d'applications. Bien qu'il soit agréable de séparer l'interface utilisateur de la logique métier et d'interaction, le modèle MVVM «pur» et la plupart des exemples disponibles fonctionnent mieux sur des vues singulières.

Je ne suis pas sûr de vos conceptions, mais la plupart de mes applications contiennent cependant des pages et plusieurs vues (réutilisables) et les ViewModels doivent donc interagir dans une certaine mesure. L'utilisation de la page en tant que contrôleur irait à l'encontre du but de la MVVM, donc ne pas utiliser une approche "VM-C" pour la logique sous-jacente pourrait entraîner ... eh bien ... des constructions difficiles à mesure que l'application mûrit. Même dans VB-6, la plupart d'entre nous ont probablement arrêté de coder la logique métier dans l'événement Button et commencé à «relayer» les commandes vers un contrôleur, non? J'ai récemment examiné de nombreux cadres émergents sur ce sujet; mon préféré est clairement l'approche Magellan (au codeplex). Bon codage!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

Le contrôleur n'est pas remplacé par un ViewModel dans MVVM, car le ViewModel a une fonctionnalité totalement différente d'un contrôleur. Vous avez toujours besoin d'un contrôleur, car sans contrôleur, votre modèle, ViewModel et View ne feront pas grand-chose ... Dans MVVM, vous avez aussi un contrôleur, le nom MVVM est simplement trompeur.

MVVMC est le nom correct à mon humble avis.

Comme vous pouvez le voir, le ViewModel n'est qu'un ajout au modèle MVC. Il déplace la logique de conversion (par exemple convertir un objet en chaîne) du contrôleur vers le ViewModel.

J'ai fait un article moyen pour cela.

MVVM

1. Voir ➡ ViewModel ➡ Modèle

   • La vue fait référence au ViewModel mais pas l'inverse.
   • Le ViewModel a une référence au modèle mais pas vice versa.
   • La vue n'a aucune référence au modèle et vice versa.

2. Si vous utilisez un contrôleur, il peut avoir une référence à Views et ViewModels , bien qu'un contrôleur ne soit pas toujours nécessaire comme illustré dans SwiftUI .

3. Liaison de données : nous créons des écouteurs pour les propriétés ViewModel.

class CustomView: UIView {
  var viewModel = MyViewModel {
    didSet {
      self.color = viewModel.color
    }
  }

  convenience init(viewModel: MyViewModel) {
    self.viewModel = viewModel
  }
}


struct MyViewModel {
   var viewColor: UIColor {
      didSet {
         colorChanged?() // This is where the binding magic happens.
      }
   }

   var colorChanged: ((UIColor) -> Void)?
}


class MyViewController: UIViewController {

   let myViewModel = MyViewModel(viewColor: .green)
   let customView: CustomView!

   override func viewDidLoad() {
      super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView
   }
}

différences de configuration

1. La logique métier est conservée dans le contrôleur pour MVC et les ViewModels pour MVVM.
2. Les événements sont transmis directement de la vue au contrôleur dans MVC tandis que les événements sont transmis de la vue au ViewModel au contrôleur (s'il y en a un) pour MVVM.

Caractéristiques communes

1. MVVM et MVC ne permettent pas à la vue d'envoyer des messages directement aux modèles.
2. Les deux ont des modèles.
3. Les deux ont des vues.

Avantages de MVVM

1. Parce que les ViewModels possèdent une logique métier, ce sont des objets concrets plus petits qui les rendent faciles à tester. D'un autre côté, dans MVC, la logique métier est dans ViewController. Comment pouvez-vous être sûr qu'un test unitaire d'un contrôleur de vue est totalement sûr sans tester simultanément toutes les méthodes et tous les écouteurs? Vous ne pouvez pas faire entièrement confiance aux résultats des tests unitaires.
2. Dans MVVM, étant donné que la logique métier est siphonnée hors du contrôleur dans des unités atomiques ViewModel, la taille du ViewController diminue et cela rend le code ViewController plus lisible.

Avantages de MVC

1. La fourniture d'une logique métier dans le contrôleur réduit le besoin de branchement et, par conséquent, les instructions sont plus susceptibles de s'exécuter sur le cache, ce qui est plus performant que l'encapsulation de la logique métier dans ViewModels.
2. Fournir la logique métier en un seul endroit peut accélérer le processus de développement d'applications simples, où les tests ne sont pas requis. Je ne sais pas quand les tests ne sont pas requis.
3. Il est plus facile de penser à la logique métier dans ViewController pour les nouveaux développeurs.

D'un point de vue pratique, MVC (Model-View-Controller) est un modèle. Cependant, MVC lorsqu'il est utilisé en tant que MVC ASP.net, lorsqu'il est combiné avec Entity Framework (EF) et les "outils électriques" est une approche très puissante et partiellement automatisée pour amener des bases de données, des tables et des colonnes sur une page Web, Opérations CRUD ou opérations R (Récupérer ou Lire) uniquement. Au moins lorsque j'utilisais MVVM, les modèles d'affichage interagissaient avec des modèles qui dépendaient d'objets métier, qui étaient à leur tour "fabriqués à la main" et après beaucoup d'efforts, on a eu la chance d'obtenir des modèles aussi bons que ce qu'EF donne ". -of-the-box ". D'un point de vue pratique de la programmation, MVC semble être un bon choix car il donne un bon nombre d'utilitaires prêts à l'emploi, mais il y a toujours un potentiel d'ajout de cloches et de sifflets.

En complément de la plupart des réponses données, je voulais ajouter une perspective supplémentaire du Web côté client moderne - ou de l' application Web riche .

En effet, de nos jours, des sites Web simples et des applications Web plus grandes sont généralement construits avec de nombreuses bibliothèques populaires telles que Bootstrap. Construit par Steve Sanderson, Knockout prend en charge le modèle MVVM qui imite l'un des comportements les plus importants du modèle: la liaison de données via le modèle de vue. Avec un peu de JavaScript, des données et une logique peuvent être implémentées qui peuvent ensuite être ajoutées à des éléments de page avec des data-bindattributs HTML simples , similaires à l'utilisation de nombreuses fonctionnalités de Bootstrap . Ensemble, ces deux bibliothèques offrent à elles seules un contenu interactif; et lorsqu'elle est combinée avec le routage, cette approche peut aboutir à une approche simple mais puissante pour créer l' application à page unique. .

De même, une infrastructure côté client moderne telle qu'Angular suit le modèle MVC par convention, mais ajoute également un service. Fait intéressant, il est présenté comme modèle-vue-peu importe (MVW). (Voir cet article sur Stack Overflow .)

De plus, avec l'essor des frameworks Web progressifs tels que Angular 2, nous assistons à un changement de terminologie et peut-être à un nouveau modèle architectural où les composants comprennent une vue ou un modèle et interagissent avec un service - qui peuvent tous être contenus dans un Module; et une série de modules compose l'application.

Je pensais que MVC et MVVM sont les mêmes. Maintenant, en raison de l'existence de Flux, je peux faire la différence:

Dans MVC, pour chaque vue de votre application, vous avez un modèle et un contrôleur, donc je l'appellerais vue, vue modèle, vue contrôleur. Le modèle ne vous indique pas comment une vue peut communiquer avec une autre. Par conséquent, dans différents cadres, il existe différentes implémentations pour cela. Par exemple, il existe des implémentations où les contrôleurs se parlent, tandis que dans d'autres implémentations, il existe un autre composant qui sert d'intermédiaire entre eux. Il existe même des implémentations dans lesquelles les modèles de vue communiquent entre eux, ce qui constitue une rupture du modèle MVC car le modèle de vue ne doit être accessible que par le contrôleur de vue.

Dans MVVM, vous disposez également d'un modèle de vue pour chaque composant. Le modèle ne spécifie pas la façon dont la vue doit influencer le modèle de vue, donc la plupart des cadres incluent généralement la fonctionnalité du contrôleur dans le modèle de vue. Cependant, MVVM vous indique que les données de votre modèle de vue doivent provenir du modèle, qui est le modèle entier qui n'est pas conscient ou personnalisé pour une vue spécifique.

Pour démontrer la différence, prenons le modèle Flux. Le modèle de flux indique comment les différentes vues de l'application doivent communiquer. Chaque vue écoute un magasin et déclenche des actions à l'aide du répartiteur. Le répartiteur informe à son tour tous les magasins de l'action qui vient d'être effectuée et les magasins se mettent à jour eux-mêmes. Un magasin dans Flux correspond au modèle (général) dans MVVM. ce n'est pas personnalisé pour une vue spécifique. Donc, généralement, lorsque les gens utilisent React et Flux, chaque composant React implémente en fait le modèle MVVM. Lorsqu'une action se produit, le modèle de vue appelle le répartiteur et, enfin, il est mis à jour en fonction des modifications du magasin, qui est le modèle. Vous ne pouvez pas dire que chaque composant implémente MVC car dans MVC seul le contrôleur peut mettre à jour le modèle de vue.

mvc est côté serveur et mvvm est côté client (navigateur) dans le développement web.

la plupart du temps, javascript est utilisé pour mvvm dans le navigateur. il existe de nombreuses technologies côté serveur pour mvc.

En très court - dans MVC Controler est au courant de la vue (contrôles), tandis que dans MVVM, ViewModel ne sait pas qui le consomme. ViewModel expose ses propriétés et actions observables à quiconque pourrait être intéressé à l'utiliser. Ce fait facilite les tests car il n'y a aucune référence à l'interface utilisateur dans ViewModel.

Model – View – Controller (généralement appelé MVC ) est un modèle de conception logicielle couramment utilisé pour développer des interfaces utilisateur qui divisent la logique de programme associée en trois éléments interconnectés. Cela permet de séparer les représentations internes des informations de la manière dont les informations sont présentées et acceptées par l'utilisateur. En suivant le modèle architectural MVC, ces composants principaux sont découplés, ce qui permet la réutilisation du code et le développement parallèle.

Traditionnellement utilisé pour les interfaces utilisateur graphiques (GUI) de bureau, ce modèle est devenu populaire pour la conception d'applications Web. Les langages de programmation populaires comme JavaScript, Python, Ruby, PHP, Java et C # ont des frameworks MVC qui sont utilisés directement dans le développement d'applications Web.

Modèle

L'élément central du motif. Il s'agit de la structure de données dynamique de l'application, indépendante de l'interface utilisateur. Il gère directement les données, la logique et les règles de l'application.

Vue

Toute représentation d'informations telle qu'un graphique, un diagramme ou un tableau. Plusieurs vues des mêmes informations sont possibles, comme un graphique à barres pour la gestion et une vue tabulaire pour les comptables.

Manette

Accepte l'entrée et la convertit en commandes pour le modèle ou la vue.

En plus de diviser l'application en ces composants, la conception modèle-vue-contrôleur définit les interactions entre eux.

Le modèle est responsable de la gestion des données de l'application. Il reçoit l'entrée utilisateur du contrôleur.

La vue signifie une présentation du modèle dans un format particulier.

Le contrôleur répond à l'entrée utilisateur et effectue des interactions sur les objets du modèle de données. Le contrôleur reçoit l'entrée, la valide éventuellement, puis transmet l'entrée au modèle.

Model – View – ViewModel (MVVM) est un modèle d'architecture logicielle.

MVVM facilite une séparation du développement de l'interface utilisateur graphique - que ce soit via un langage de balisage ou un code GUI - du développement de la logique métier ou de la logique back-end (le modèle de données). Le modèle de vue de MVVM est un convertisseur de valeur, ce qui signifie que le modèle de vue est responsable de l'exposition (conversion) des objets de données du modèle de telle manière que les objets sont facilement gérés et présentés. À cet égard, le modèle de vue est plus un modèle qu'une vue et gère la plupart sinon la totalité de la logique d'affichage de la vue. Le modèle de vue peut implémenter un modèle de médiateur, organisant l'accès à la logique principale autour de l'ensemble des cas d'utilisation pris en charge par la vue.

MVVM est une variation du modèle de conception du modèle de présentation de Martin Fowler. MVVM résume l'état et le comportement d'une vue de la même manière, mais un modèle de présentation résume une vue (crée un modèle de vue) d'une manière qui ne dépend pas d'une plate-forme d'interface utilisateur spécifique.

MVVM a été inventé par les architectes Microsoft Ken Cooper et Ted Peters spécifiquement pour simplifier la programmation événementielle des interfaces utilisateur. Le modèle a été intégré dans Windows Presentation Foundation (WPF) (système graphique .NET de Microsoft) et Silverlight (dérivé d'application Internet de WPF). John Gossman, l'un des architectes Microsoft WPF et Silverlight, a annoncé MVVM sur son blog en 2005.

Model – View – ViewModel est aussi appelé model – view – binder, en particulier dans les implémentations n'impliquant pas la plate-forme .NET. ZK (un cadre d'application Web écrit en Java) et KnockoutJS (une bibliothèque JavaScript) utilisent un modèle, une vue et un classeur.