Quelle est la différence entre MVC et MVVM?

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

MVC / MVVM n’est pas un choix ou un choix.

Les deux modèles se présentent, 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 de manière bidirectionnelle dans les vues. Il s’agit généralement d’une implémentation côté client (par exemple, en utilisant Knockout.js). MVC est un moyen de séparer les problèmes côté serveur .

Pour Silverlight et WPF, le modèle MVVM est plus complet et peut sembler remplacer MVC (ou d’autres modèles d’organisation de logiciels dans des responsabilités distinctes). Une hypothèse, qui est souvent sortie de ce modèle, était que ViewModel remplaçait simplement le contrôleur dans MVC (comme si vous pouviez simplement substituer VM pour C dans l’acronyme et que tout serait pardonné) …

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

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 surtout, de la provenance de ses données .

* Remarque: en pratique, les contrôleurs suppriment la plus grande partie de la logique, à partir de ViewModel, qui nécessite des tests unitaires. La machine virtuelle devient alors un conteneur idiot qui nécessite peu ou pas de tests. C’est une bonne chose car la VM n’est qu’un pont entre le concepteur et le codeur.

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-behind pour que l’édition XAML devienne 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 de MVCVM que nous suivons sont les suivantes:

  • Les vues affichent une certaine forme de données . Ils n’ont aucune idée d’où proviennent 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 ou comment elles sont affichées.
  • Les modèles contiennent les données réelles (diverses méthodes de contexte, de magasin ou autres)
  • 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 ViewModel soit réellement réutilisable.

Nous avons également noté que le framework de génération de code Sculpture implémente MVVM et un modèle similaire à Prism. Il utilise également largement les contrôleurs pour séparer toute la logique des cas d’utilisation.

Ne supposez pas que les contrôleurs sont obsolètes avec les modèles View.

J’ai commencé un blog sur ce sujet que je vais append au fur et à mesure que je le pourrai . La combinaison de MVCVM avec les systèmes de navigation courants pose des problèmes, car la plupart des systèmes de navigation utilisent uniquement les vues et les 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 objects de contrôleur doivent exister en mémoire pour la durée de vie de l’application et que les contrôleurs contiennent principalement du code et des données d’état réduites (minuscule surcharge 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 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 occasionnellement pour la réactivité.

Remarque: Ce message a été modifié à de nombreuses resockets et n’a pas spécifiquement ciblé la question précise posée. J’ai donc mis à jour la première partie pour couvrir cette question. Une grande partie de la discussion, dans les commentaires ci-dessous, ne concerne que ASP.Net et non l’ensemble. Cet article était destiné à couvrir l’utilisation plus large de MVVM dans Silverlight, WPF et ASP.Net et à éviter de remplacer les contrôleurs par ViewModels.

Je pense que la meilleure façon de comprendre ce que ces acronymes signifient est de les oublier un instant. Au lieu de cela, pensez au logiciel dont ils sont issus, chacun d’eux. Cela se résume vraiment à la différence entre le début du Web et le bureau.

Le premier acronyme, MVC, provient du web. (Oui, peut-être y était-il déjà arrivé, mais le Web est devenu populaire auprès des nombreux développeurs Web.) Pensez à la firebase database, aux pages HTML et au code. Affinons cela un peu pour arriver à MVC: Pour «database», supposons une firebase database plus un code d’interface. Pour les «pages HTML», supposons les modèles HTML et le code de traitement des modèles. Pour «code inbetween», supposons que l’utilisateur qui clique sur le code pour effectuer des actions affecte éventuellement la firebase database, provoquant définitivement l’affichage d’une autre vue. C’est tout, au moins pour les besoins de cette comparaison.

Retenons une caractéristique de ce genre de Web, non pas telle qu’elle est aujourd’hui, mais telle qu’elle existait il ya dix ans, lorsque le Javascript était un désagrément humble, que les vrais programmeurs ont bien évité: La page HTML est essentiellement stupide et passive . Le navigateur est un client léger ou, si vous voulez, un client médiocre. Il n’y a pas d’intelligence dans le navigateur. Règle de recharge complète de la page. La «vue» est à nouveau générée à chaque fois.

Souvenons-nous que cette méthode Web, bien qu’elle fasse fureur, é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 un type de client, un client pour les documents.) Ce sont des clients pleins d’intelligence, qui connaissent bien leurs données. Ils sont en état Ils mettent en cache les données qu’ils traitent en mémoire. Pas de conneries comme un rechargement complet de la page.

Et cette méthode de bureau riche est probablement celle du second acronyme, MVVM. Ne vous laissez pas berner par les lettres, par l’omission du C. Les contrôleurs sont toujours là. Ils doivent être. Rien n’est enlevé. Nous venons d’append une chose: l’etatualité, 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 interactivité riche. Et c’est tout.

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

Nous pouvons voir que, avec Flash, Silverlight et, surtout, 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 que cette affaire de théorie et d’acronyme est plus facile à comprendre en examinant 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 des matériaux concrets, de sorte que la compréhension peut être bouclée.

MVM 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. ViewModel expose les objects de données et de commande dont la vue a besoin. Vous pouvez penser à cela comme un object conteneur dont la vue permet d’obtenir ses données et ses actions. Le ViewModel extrait ses données du modèle.

Russel East fait un blog 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’en plus des données (“le modèle”), il existe une autre couche de composants non visuels (“ViewModel”) qui mappe plus étroitement les concepts des données. aux concepts de la vue des données (“la vue”). C’est le ViewModel auquel la vue se lie, pas directement le modèle.

Vous pouvez voir une explication du pattern 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. entrer la description de l'image ici

  • Modèle : Ceci représente le modèle de données utilisé par votre application. 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.

  • 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 voit l’utilisateur. Les données du modèle sont affichées à l’utilisateur, et le rôle de ViewModel est de fournir à 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 affiche à l’utilisateur la liste des albums du périphérique, les images d’un album et peut-être une autre qui montre à l’utilisateur une image particulière.

  • ViewModel : 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 à partir du modèle et expose les données en tant qu’ensemble de propriétés auxquelles l’interface utilisateur ou les vues XAML peuvent se lier. Par exemple, dans une application de partage d’images, ViewModel exposerait une liste d’albums et exposerait une liste d’images pour chaque album. L’interface utilisateur est indépendante de l’origine des images et de leur récupération. Il connaît simplement un ensemble d’images tel qu’exposé par le ViewModel et les affiche à l’utilisateur.

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

Si je ne suis pas plein de bric-à-brac, 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.

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

entrer la description de l'image ici

MVC (contrôleur de vue de modèle)

  1. Modèles: les modèles contiennent des informations de données. Ne pas appeler ou utiliser Controller et View. Contient la logique métier et les moyens de représenter les données. Certaines de ces données, sous une forme ou une autre, 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 lien entre la vue et le modèle. Afficher les appels Controller and Controller appelle le modèle. Il informe fondamentalement le modèle et / ou la vue de changer le cas échéant.
  3. Afficher: traite de la partie interface utilisateur. 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 aux événements de visualisation, alias la logique de présentation.
  4. Appelle d’autres fonctionnalités pour le traitement de la logique métier.
  5. Ne demande jamais directement l’affichage pour 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 de la liaison de données et du traitement 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 objects de modèle pour refléter l’état de votre vue, par exemple pour afficher et masquer une boîte de dialog 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 est ajouté, c’est que les liaisons de données WPF / Silverlight sont particulièrement bien adaptées pour travailler avec ce modèle. Mais rien ne vous empêche de l’utiliser avec des faces de serveur Java, par exemple.

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 vues et en logique dynamic. La création vit sur le serveur et dynamic sur le client. Vous voyez ceci avec ASP.NET MVC combiné avec AngularJS alors que le serveur créera une vue et transmettra un modèle et l’enverra au client. Le client va alors interagir 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 du serveur et traité. (Ainsi le cycle continue et il y a beaucoup d’autres traductions de cette manipulation quand on travaille avec des sockets ou AJAX etc. mais sur tout 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 sera activé en fonction de certains événements. Dans XAML, où MVVM prospère, cela se fait facilement avec le framework 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 propriété modifié) et la vue réagit en fonction des déclencheurs que vous créez. Cela peut devenir technique mais la ligne du bas 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 essentiellement une logique zéro car ils ne devraient conserver que l’état. Je décris ceci comme état d’application (modèle), traducteur d’état (ViewModel), puis état visuel / interaction (vue).

Dans un bureau ou une application client MVC, vous devez avoir un modèle et le modèle doit être utilisé par le contrôleur. Basé sur le modèle, le contrôleur modifiera la vue. Les vues sont généralement associées à des contrôleurs dotés d’interfaces afin que le contrôleur puisse fonctionner avec diverses vues. Dans ASP.NET, la logique de MVC est légèrement inversée sur le serveur lorsque le contrôleur gère les modèles et transmet les modèles à une vue sélectionnée. La vue est alors remplie de données basées sur le modèle et possède sa propre logique (généralement un autre ensemble MVC, comme avec AngularJS). Les gens vont se disputer et faire en sorte que l’application soit confondue avec MVC et essayer de faire les deux à un moment où la maintenance du projet finira par devenir un désastre. TOUJOURS mettre la logique et le contrôle en un seul endroit lors de l’utilisation de MVC. N’écrivez PAS la logique d’affichage dans le code derrière la vue (ou dans la vue via JS pour le Web) pour prendre en charge les données du contrôleur ou du modèle. Laissez le contrôleur modifier la vue. La SEULE logique qui doit vivre dans une vue est tout ce qu’il faut pour créer et exécuter via l’interface utilisée. Un exemple de ceci est la soumission d’un nom d’utilisateur et d’un mot de passe. Qu’il s’agisse d’une page Web ou de bureau (sur le client), le contrôleur doit gérer le processus d’envoi chaque fois que la vue déclenche l’action Soumettre. Si cela est fait correctement, vous pouvez toujours trouver votre chemin autour d’une application Web ou locale MVC.

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

Voici un petit exemple: Supposons que vous souhaitiez insérer un menu dans un bouton. Dans MVC, vous aurez une action MenuPressed dans votre interface. Le contrôleur saura lorsque vous cliquerez sur le bouton Menu, puis indiquera à 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 avec la vue ne faisant rien à moins que le contrôleur ne le dise. TOUTEFOIS; Dans MVVM, le menu de diapositives de l’animation devrait être intégré et générique et, au lieu de lui demander de le glisser, il le fera en fonction de certaines valeurs. Donc, il écoute le ViewModel et quand le ViewModel dit IsMenuActive = true (ou cependant) l’animation pour cela a lieu. Maintenant, avec cela dit je veux faire un autre point VRAIMENT CLEAR et VEUILLEZ prêter attention. IsMenuActive est probablement la conception BAD MVVM ou ViewModel. Lors de la conception d’un ViewModel, vous ne devez jamais supposer qu’un View aura des fonctionnalités et qu’il suffit de passer l’état du modèle traduit. De cette façon, si vous décidez de modifier votre vue pour supprimer le menu et afficher simplement les données / options d’une autre manière, ViewModel s’en moque. Alors, comment gérez-vous le menu? Lorsque les données ont du sens, c’est comme ça. Ainsi, une façon de 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 ViewModel. Ne décidez pas d’afficher / masquer ces données dans ViewModel .. traduisez 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 familiarisé avec l’architecture de chacun et qu’il peut être très déroutant d’apprendre que vous trouverez des informations ALOT OF BAD sur le net.

Alors … des choses à garder à l’esprit pour bien faire les choses. Décidez comment concevoir votre application et STICK TO IT.

Si vous faites MVC, ce qui est formidable, assurez-vous que votre contrôleur est gérable et qu’il contrôle entièrement votre vue. Si vous avez une vue importante, ajoutez des contrôles à la vue qui ont des contrôleurs différents. JUSTE NE PAS mettre en cascade ces contrôleurs à différents contrôleurs. Très frustrant à entretenir. Prenez un moment et concevez les choses séparément de manière à ce qu’elles fonctionnent 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 View ← Controller → Model ou avec ASP.NET (ne me lancez pas) Model ← View ↔ Controller → Model (où Model peut être le même ou un modèle totalement différent de Controller à View) … bien sûr, le seul besoin de connaître Controller in View à ce stade est principalement lié à la référence du sharepoint terminaison pour savoir où retourner un modèle.

Si vous faites MVVM, je bénis votre âme, mais prenez le temps de le faire DROIT! N’utilisez pas d’interfaces pour un. Laissez votre vue décider de la manière dont elle va se baser sur les valeurs. Jouez avec la vue avec des données factices. Si vous finissez par avoir une vue qui vous montre un menu (comme dans l’exemple) même si vous ne le vouliez pas à l’époque, alors bon. Votre avis 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 ViewModel se trouve dans un état traduit particulier ou commandez ViewModel pour vider cet état. Dans votre ViewModel, ne supprimez PAS cela avec la logique interne, comme si vous décidiez de voir si la vue devait ou non le voir. N’oubliez pas que vous ne pouvez pas supposer qu’il existe un menu ou non dans ViewModel. Et enfin, le modèle devrait juste vous permettre de changer et probablement l’état du magasin. C’est où la validation et tout se passera; Par exemple, si le modèle ne peut pas modifier l’état, il se marquera simplement comme étant sale ou quelque chose. Lorsque le ViewModel s’en rend compte, il traduit ce qui est sale et la vue le réalise alors et affiche des informations via un autre déclencheur. Toutes les données de la vue peuvent être liées à ViewModel afin que tout puisse être dynamic, seuls le modèle et ViewModel n’ont absolument aucune idée de la réaction de la vue à la liaison. En fait, le modèle n’a aucune idée d’un ViewModel non plus. Lorsque vous configurez des dépendances, elles doivent pointer comme ça et seulement comme ça: View → ViewModel → Model (et une note latérale ici … et cela sera probablement aussi discuté mais je m’en fiche … NE PAS PASSER LE MODÈLE à the view La vue ne devrait pas voir une période modèle, je donne à un rat la démo que vous avez vue ou comment vous l’avez fait, c’est faux.)

Voici mon dernier conseil … Regardez une application MVC bien conçue, mais très simple, et faites de même pour une application MVVM. On 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é permet de gérer l’ensemble de l’application à partir d’un ensemble de contrôleurs ou (une source unique), tandis qu’un environnement réactif peut être divisé en plusieurs référentiels sans aucune idée de ce que fait le rest de l’application. Micro gestion vs gestion libre.

Si je ne vous ai pas encore confondu, essayez de me contacter … Cela ne me dérange pas d’aller plus en détail avec des illustrations et des exemples.

En fin de compte, nous sums tous des programmeurs et avec cette anarchie, nous vivons en codant … Alors les règles seront brisées, les théories changeront et tout cela finira par se casser la gueule … Mais en travaillant sur de grandes projets et sur de grandes équipes, cela aide vraiment à se mettre d’accord sur un modèle de conception et à l’appliquer. Un jour, les petites mesures supplémentaires sockets au début deviendront plus tard des économies considérables.

MVVM ajoute le modèle de vue au mixage. This is important, as it allows you to use a lot of the binding approach of WPF, without putting all that UI specific pieces in your regular model.

I may be wrong, but I am not sure MVVM really forces the controller into the mix. I find the concept to be more in line with: http://martinfowler.com/eaaDev/PresentationModel.html . I think that people choose to combine it with MVC, not that it is built in into the pattern.

From what I can tell, the MVVM maps to the MV of MVC – meaning that in a traditional MVC pattern the V does not communicate directly with the M. In the second version of MVC, there is a direct link between M and V. MVVM appears to take all tasks related to M and V communication, and couple it to decouple it from the C. In effect, there’s still the larger scope application workflow (or implementation of the use scenarios) that are not fully accounted for in MVVM. This is the role of the controller. By removing these lower level aspects from the controllers, they are cleaner and makes it easier to modify the application’s use scenario and business logic, also making controllers more reusable.

Injecting Strongly Typed ViewModels into the View using MVC

  1. The controller is responsible for newing up the ViewModel and injecting it into the View. (for get requests)
  2. The ViewModel is the container for DataContext and view state such as the last selected item etc.
  3. The Model contains DB entities and is very close to the DB Schema it does the queries and filtering. (I like EF and LINQ for this)
  4. The Model should also consider repositories and or projection of results into strong types (EF has a great method… EF.Database.Select(queryssortingng, parms) for direct ADO access to inject queries and get back strong types. This addresses the EF is slow argument. EF is NOT SLOW !
  5. The ViewModel gets the data and does the business rules and validation
  6. The controller on post back will cal the ViewModel Post method and wait for results.
  7. The controller will inject the newly updated Viewmodel to the View. The View uses only strong type binding .
  8. The view merely renders the data, and posts events back to the controller. (see examples below)
  9. MVC intercepts the inbound request and routes it to proper controller with strong data type

In this model there is no more HTTP level contact with the request or response objects as MSFT’s MVC machine hides it from us.

In clarification of item 6 above (by request)…

Assume a ViewModel like this:

 public class myViewModel{ public ssortingng SelectedValue {get;set;} public void Post(){ //due to MVC model binding the SelectedValue ssortingng 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!"; } } 

The controller method of the post will look like this (See below), note that the instance of mvm is automatically instanciated by the MVC binding mechanisms. You never have to drop down to the query ssortingng layer as a result! This is MVC instantiating the ViewModel for you based on the query ssortingngs!

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

Note that in order for this actionmethod above to work as you intend, you must have a null CTOR defined that intializes things not returned in the post. The post back must also post back name/value pairs for those things which changed. If there are missing name/value pairs the MVC binding engine does the proper thing which is simply nothing! If this happens you might find yourself saying “I’m losing data on post backs”…

The advantage of this pattern is the ViewModel does all the “clutter” work interfacing to the Model/Buisness logic, the controller is merely a router of sorts. It is SOC in action.

It sursockets me that this is a highly voted answers without mentioning the origin of MVVM. MVVM is a popular term used in Microsoft community and it is originated from Martin Fowler’s Presentation Model . So to understand the motive of the pattern and the differences with others, the original article about the pattern is the first thing to read.

Well, generally MVC is used in Web development and MVVM is most popular in WPF/Silverlight development. However, sometimes the web architecute might have a mix of MVC and MVVM.

For example: you might use knockout.js and in this case you will have MVVM on your client side. And your MVC’s server side can also change. In the complex apps, nobody uses the pure Model. It might have a sense to use a ViewModel as a “Model” of MVC and your real Model basically will be a part of this VM. This gives you an extra abstraction layer.

MVVMC, or perhaps MVC+, seems to be a viable approach for enterprise as well as rapid application development. While it is nice to separate the UI from business and interaction logic, the ‘pure’ MVVM pattern and most available examples work best on singular views.

Not sure about your designs, but most of my applications, however, contain pages and several (reusable) views and thus the ViewModels do need to interact to some degree. Using the page as controller would defeat the purpose of the MVVM altogether, so not using a “VM-C” approach for the underlying logic might result in .. well .. challenging constructs as the application matures. Even in VB-6 most of us probably stopped coding business logic into the Button event and started ‘relaying’ commands to a controller, right? I recently looked at many emerging framworks on that topic; my favorite clearly is the Magellan (at codeplex) approach. Happy coding!

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

From a practical point of view, MVC (Model-View-Controller) is a pattern. However, MVC when used as ASP.net MVC, when combined with Entity Framework (EF) and the “power tools” is a very powerful, partially automated approach for bringing databases, tables, and columns to a web-page, for either full CRUD operations or R (Resortingeve or Read) operations only. At least as I used MVVM, the View Models interacted with models that depended upon business objects, which were in turn “hand-made” and after a lot of effort, one was lucky to get models as good as what EF gives one “out-of-the-box”. From a practical programming point of view, MVC seems a good choice because it gives one lots of utility out-of-box, but there is still a potential for bells-and-whistles to be added.

Complementary to many of the responses given, I wanted to add some additional perspective from the Modern client-side web – or Rich Web Application point of view.

Indeed these days simple web sites and larger web applications are commonly built with many popular libraries such as Bootstrap. Built by Steve Sanderson, Knockout provides support for the MVVM pattern which mimics one of the most important behaviors in the pattern: data-binding through the View Model. With a little JavaScript, data and logic can be implemented that can then be added to page elements with simple data-bind HTML atsortingbutes, similar to using many of the features of Bootstrap . Together, these two libraries alone offer interactive content; and when combined with routing this approach can result in a simple-yet-powerful approach to building the Single Page Application .

Similarly, a Modern client-side framework such as Angular follows the MVC pattern by convention, but also adds a Service. Interestingly, it is touted as Model-View-Whatever (MVW). (See this post on Stack Overflow .)

Additionally, with the rise of Progressive web frameworks such as Angular 2, we’re seeing a change in terminology and perhaps a new architectural pattern where Components comprise of a View or Template and interact with a Service – all of which can be contained in a Module; and a series of Modules makes up the application.

I used to think that MVC and MVVM are the same. Now because of the existence of Flux I can tell the difference:

In MVC, for each view in your app, you have a model and a controller, so I would call it view, view model, view controller. The pattern does not tell you how one view can communicate with another. Therefore, in different frameworks there are different implementations for that. For example there are implementations where controllers talk to each other whereas in other implementations there’s another component that mediates between them. There are even implementations in which the view models communicate with each other, which is a break of the MVC pattern because the view model should only be accessed by the view controller.

In MVVM, you also have a view model for each component. The pattern does not specify how the heck the view should influence the view model, so usually most frameworks just include controller’s functionality in the view model. However, MVVM does tell you that your view model’s data should come from the model, which is the entire model that’s not aware or custom to a specific view.

To demonstrate the difference, let’s take Flux pattern. Flux pattern tells how different views in the app should communicate. Each view listens to a store and fires actions using the dispatcher. The dispatcher in turn tells all the stores about the action that was just made, and the stores update themselves. A store in Flux corresponds to the (general) model in MVVM. it’s not custom to any specific view. So usually when people use React and Flux, each React component actually implements the MVVM pattern. When an action occurs, the view model calls the dispatcher, and finally it’s getting updated according to the changes in the store, which is the model. You can’t say that each component implements MVC because in MVC only the controller can update the view model. So MVVM can work with Flux together (MVVM handles the communication between the view and the view model, and Flux handles the communication between different views), whereas MVC can’t work with Flux without breaking a key principle.

mvc is server-side and mvvm is client-side(browser) in web development.

most of the time javascript is used for mvvm in browser. there are many server side technologies for mvc.

The other answers might not be easy to understand for one who is not much familiar with the subject of architectural patterns. Someone who is new to app architecture might want to know how its choice can affect her app in practice and what all the fuss is about in communities.

Trying to shed some light on the above, I made up this screenplay involving MVVM, MVP and MVC. The story begins by a user clicking on the ‘FIND’ button in a movie search app… :

User: Click …

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

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

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

( View calling the ViewModel | Presenter | Controller … ) [ MVVM|MVP|MVC ]

View : 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 | Controller : Hey View , y a-t-il un terme de recherche sur cette page? [ MVVM|MVP|MVC ]

View : Yes,… here it is … “piano” [ MVVM|MVP|MVC ]

—— This is the most important difference between MVVM AND MVP | MVC ———

Présentateur : Merci Voir ,… pendant que je cherche le terme de recherche sur le modèle , montrez-lui s’il vous plaît une barre de progression [ MVP | MVC ]

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

ViewController : Thanks, I’ll be looking up the search term on the Model but will not update you directly. Instead, I will sortinggger events to searchResultsListObservable if there is any result. So you had better observe on that. [ MVVM ]

(While observing on any sortinggger in searchResultsListObservable, the View thinks it should show some progress bar to the user, since ViewModel would not talk to it on that)

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

ViewModel | Présentateur | Controller : Hey Model , Do you have any match for this search term?: “piano” [ MVVM | MVP | MVC ]

Model : Hey ViewModel | Présentateur | Controller , let me check … [ MVVM | MVP | MVC ]

( Model is making a query to the movie database … ) [ MVVM | MVP | MVC ]

( After a while … )

———— This is the diverging point between MVVM , MVP and MVC ————–

Model : I found a list for you, ViewModel | Presenter , here it is in JSON “[{“name”:”Piano Teacher”,”year”:2001},{“name”:”Piano”,”year”:1993}]” [ MVVM | MVP ]

Model : There is some result available, Controller. J’ai créé une variable de champ dans mon instance et l’ai remplie avec le résultat. It’s name is “searchResultsList” [ MVC ]

( Présentateur | Contrôleur remercie Model et revient à la vue ) [ MVP | MVC ]

Presenter : Thanks for waiting View , I found a list of matching results for you and arranged them in a presentable format: [“Piano Teacher 2001″,”Piano 1993”]. Veuillez également masquer la barre de progression maintenant [ MVP ]

Controller : Thanks for waiting View , I have asked Model about your search query. It says it has found a list of matching results and stored them in a variable named “searchResultsList” inside its instance. Vous pouvez l’obtenir à partir de là. Veuillez également masquer la barre de progression maintenant [ MVC ]

ViewModel : Any observer on searchResultsListObservable be notified that there is this new list in presentable format: [“Piano Teacher 2001″,”Piano 1993”].[ MVVM ]

View : Thank you very much Presenter [ MVP ]

View : Thank you “ Controller ” [ MVC ] (Now the View is questioning itself: How should I present the results I get from the Model to the user? Should the production year of the movie come first or last…?)

View : Oh, there is a new sortinggger in searchResultsListObservable … , good, there is a presentable list, now I only have to show it in a list. I should also hide the progress bar now that I have the result. [ MVVM ]

In case you are interestd, I have written a series of articles here , comparing MVVM, MVP and MVC by implementing a movie search android app.

The Controller is not replaced by a ViewModel in MVVM, because the ViewModel has a totally different functionality then a Controller. You still need a Controller, because without a Controller your Model, ViewModel and View will not do much… In MVVM you have a Controller too, the name MVVM is just missleading.

MVVMC is the correct name in my humble opinion.

As you can see the ViewModel is just an addition to the MVC pattern. It moves conversion-logic (for example convert object to a ssortingng) from the Controller to the ViewModel.