model-view-controller - vue - pourquoi choisir mvvm




Quelle est la différence entre MVC et MVVM? (14)

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

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 lier les données dans les deux vues. C'est généralement une implémentation côté client (par exemple en utilisant Knockout.js). MVC, d'un autre côté, est un moyen de séparer les problèmes du côté serveur .

Pour Silverlight et WPF, le modèle MVVM est plus englobant et peut sembler agir en remplacement de MVC (ou d'autres modes d'organisation du logiciel en responsabilités distinctes). Une hypothèse, qui est souvent sortie de ce schéma, était que le ViewModel remplaçait simplement le contrôleur dans MVC (comme si vous pouviez simplement remplacer VM par C dans 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 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 surtout pas d'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-behind XAML pour 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:

  • Les vues affichent une certaine forme de données . Ils n'ont aucune idée d'où proviennent les données.
  • ViewModels contient une certaine forme de données et de commandes , ils ne savent pas d'où proviennent les données, ni le code, ni comment il est affiché.
  • Les modèles contiennent les données réelles (contexte divers, 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 la structure code-gen de Sculpture implémente MVVM et un modèle similaire à Prism ET qu'elle fait également un usage intensif des 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 que je le peux . 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 toute la durée de vie de l'application et que les contrôleurs contiennent principalement des données de code et de petit état (p. Ex. 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.

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


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(querystring, 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 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!";
 }
}

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 string layer as a result! This is MVC instantiating the ViewModel for you based on the query strings!

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


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

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

  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 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. Contrôleur: agit comme la connexion 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. Voir: Offres avec une partie de l'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 à 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.

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.


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 d'une 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 viewmodel.

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é 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 serveurs Java, par exemple.


MVVM ajoute le modèle de vue dans le mix. Ceci est important, car il vous permet d'utiliser une grande partie de l'approche de liaison de WPF, sans mettre toutes les pièces spécifiques à cette interface dans votre modèle habituel.

Je peux me tromper, mais je ne suis pas sûr que MVVM force vraiment le contrôleur dans le mélange. Je trouve le concept plus en accord avec: 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 modèle.


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.

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

  • Affichage : 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.


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

Le contrôleur 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


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 attributes, 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 .)

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.


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 (Retrieve 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.


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.


It surprises 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.


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.