Question Quelle est la différence entre MVC et MVVM?


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


1097
2018-03-20 20:09


origine


Réponses:


MVC / MVVM n'est pas un soit choix.

Les deux modèles apparaissent de différentes manières dans les développements ASP.Net et Silverlight / WPF.

Pour ASP.Net, MVVM est utilisé pour Liaison bidirectionnelle données dans les vues. C'est généralement une implémentation côté client (par exemple en utilisant Knockout.js). MVC d'autre part est un moyen de séparer les préoccupations du côté serveur.

Pour Silverlight et WPF, le modèle MVVM est plus englobant et peut apparaître agir comme un remplaçant pour MVC (ou d'autres modèles d'organisation de logiciels dans des responsabilités distinctes). Une hypothèse, qui est souvent sorti de ce schéma, était que le ViewModel simplement remplacé le contrôleur dans MVC (comme si vous pouviez simplement le remplacer VM pour C dans l'acronyme et tout serait pardonné) ...

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

Le problème est le suivant: pour être testable de manière indépendante *, et surtout réutilisable en cas de besoin, un view-model n'a aucune idée de ce que la vue affiche, mais plus important encore aucune idée d'où proviennent ses données.

* Remarque: en pratique, les contrôleurs suppriment la plupart des logiques, à partir du ViewModel, qui nécessitent des tests unitaires. La machine virtuelle devient alors un conteneur bête qui nécessite peu de tests, voire aucun. C'est une bonne chose car la VM n'est qu'un pont, entre le concepteur et le codeur, elle devrait donc rester simple.

Même dans MVVM, les contrôleurs contiendront généralement toute la logique de traitement et décideront quelles données afficher dans quelles vues utiliser les modèles de vue.

De ce que nous avons vu jusqu'ici le principal avantage du modèle ViewModel pour supprimer le code du code XAML derrière faire de l'édition XAML une tâche plus indépendante. Nous créons toujours des contrôleurs, au besoin, pour contrôler (sans jeu de mots) la logique globale de nos applications.

Les directives de base MVCVM que nous suivons sont:

  • Vues afficher une certaine forme de données. Ils n'ont aucune idée d'où proviennent les données.
  • ViewModels tenir une certaine forme de données et de commandes, ils ne savent pas d'où viennent les données, ni le code, ni comment ils sont affichés.
  • Des modèles détenir les données réelles (divers contexte, magasin ou autres méthodes)
  • Les contrôleurs écoutent et publient des é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 Sculpture code-gen cadre implémente MVVM et un modèle similaire à Prism ET utilise également beaucoup de contrôleurs pour séparer toute logique d'utilisation.

Ne supposez pas que les contrôleurs sont rendus obsolètes par View-models.

J'ai commencé un blog sur ce sujet que je vais ajouter au fur et à mesure. La combinaison de MVCVM avec les systèmes de navigation courants présente des problèmes, car la plupart des systèmes de navigation utilisent simplement 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 la vie de l'application et les contrôleurs contiennent principalement des données de code et de petit état (c'est-à-dire un minuscule en-tête de mémoire). Cela rend les applications beaucoup moins gourmandes en mémoire que les solutions où les modèles de vue doivent être conservés et il est idéal pour certains types de développement mobile (par exemple Windows Mobile en utilisant Silverlight / Prism / MEF). Cela dépend bien sûr du type d'application, car il se peut que vous deviez conserver les machines virtuelles mises en cache occasionnellement pour la réactivité.

Note: Ce message a été édité plusieurs fois, et n'a pas spécifiquement ciblé la question étroite posée, donc j'ai mis à jour la première partie pour la couvrir maintenant aussi. Une grande partie de la discussion, dans les commentaires ci-dessous, concerne uniquement ASP.Net et non l'image plus large. Ce post était destiné à couvrir l'utilisation plus large de MVVM dans Silverlight, WPF et ASP.Net et à éviter les gens qui remplacent les contrôleurs avec ViewModels.


578
2017-08-22 09:19



Je pense que la façon la plus simple de comprendre ce que ces acronymes sont censés signifier est de les oublier un moment. Au lieu de cela, pensez au logiciel dont ils sont originaires, chacun d'entre eux. Cela se résume à la différence entre le Web et le bureau.

Le premier acronyme, MVC, est apparu sur le web. (Oui, il peut avoir été là avant, mais le Web est comment il a été popularisé à la masse des développeurs Web.) Pensez à la base de données, les pages HTML, et le code entre. Affinons cela juste un petit peu pour arriver à MVC: Pour «base de données», supposons que la base de données plus le code d'interface. Pour les pages HTML, supposons les modèles HTML plus le code de traitement des modèles. Pour «code inbetween», supposons que le clavardage du code clique sur les actions, affectant éventuellement la base de données, provoquant définitivement l'affichage d'une autre vue. C'est tout, au moins dans le but de cette comparaison.

Gardons une caractéristique de ce web, pas comme aujourd'hui, mais comme il y a dix ans, quand Javascript était un ennui minable et méprisable, que les vrais programmeurs ont bien évité: La page HTML est essentiellement bête 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. Règle de rechargement de page complète. La «vue» est générée à chaque fois.

Souvenons-nous que cette façon de faire du Web, malgré sa rage, était horriblement rétrograde 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 un type de client, un client pour les documents.) Ce sont des clients pleins d'intelligence, pleins de connaissances sur leurs données. Ils sont stateful. Ils mettent en cache les données qu'ils manipulent en mémoire. Pas de merde comme un rechargement de page complète.

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

  • MVC = modèle, contrôleur, vue = communication essentiellement unidirectionnelle = interactivité médiocre
  • 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 cette acronymie plus faciles à comprendre en regardant ce à 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 être bouclée.


213
2018-02-13 14:11



MVVM  Model-View ViewModel est similaire à MVC, Modèle Vue Contrôleur

Le controlle est remplacé par un ViewModel. Le ViewModel se trouve en dessous de la couche d'interface utilisateur. Le ViewModel expose les objets de données et de commandes dont la vue a besoin. Vous pourriez considérer cela comme un objet conteneur dont la vue va obtenir ses données et ses actions. 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


166
2018-03-20 20:18



D'une part, MVVM est une progression du modèle MVC qui utilise XAML pour gérer l'affichage. Cet article décrit quelques-unes 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 existe une autre couche de composants non-visuels ("le ViewModel") qui mappent 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 View se lie, pas directement le Model.


85
2018-03-20 20:17



Vous pouvez voir une explication du modèle MVVM dans l'environnement Windows:

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

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

  • Vue: Une application est généralement composée de plusieurs pages d'interface utilisateur. Chaque page affichée à l'utilisateur est une vue de la terminologie MVVM. La vue est le code XAML utilisé pour définir et définir ce que l'utilisateur voit. Les données du modèle sont affichées à l'utilisateur, et c'est le travail de ViewModel pour alimenter 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 sont 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 sous la forme d'un ensemble de propriétés auxquelles l'interface utilisateur XAML, ou vues, peut se lier. Par exemple, dans une application de partage d'images, le ViewModel expose une liste d'albums et expose pour chaque album une liste d'images. L'interface utilisateur est agnostique d'où viennent les images et comment elles sont récupérées. Il connaît simplement un ensemble d'images tel qu'il est exposé par le ViewModel et les montre à l'utilisateur.


44
2018-06-12 20:48



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, alors que dans MVVM, votre VM agit comme un proxy M, en plus de fournir la fonctionnalité disponible V.

Si je ne suis pas plein de camelote, je suis surpris que personne n'ait créé un hybride, où votre VM est simplement un proxy M, et C fournit toutes les fonctionnalités.


35
2018-05-21 11:38



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

enter image description here

MVC (Modèle Vue Contrôleur)

  1. Des 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 moyens 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. Manette: Agit comme le lien entre la vue et le modèle. Afficher les appels Le contrôleur et le contrôleur appellent le modèle. Il informe fondamentalement le modèle et / ou la vue pour changer le cas échéant.
  3. Vue: Traite avec une partie de l'interface utilisateur. Interagit avec l'utilisateur.

MVVM (Modèle Voir le modèle)

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 à afficher des événements, aka 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.

17
2017-12-14 00:20



MVVM est un raffinement (discutable) du Modèle de présentation modèle. Je dis discutable, parce que la seule différence est dans la façon dont WPF fournit la capacité de faire la liaison de données et la gestion des commandes.


16
2018-03-27 21:22