Modèle ASP.NET MVC vs ViewModel

OK, j'ai entendu parler de "ViewModels" en ce qui concerne ASP.NET MVC de MS.

Maintenant, c'est censé être un type spécifique de modèle, n'est-ce pas? Pas un type de vue spécifique.

À ma connaissance, c'est une sorte de modèle qui a un but spécifique d'interagir avec la vue? Ou quelque chose comme ça?

Des éclaircissements seraient appréciés.

Le modèle et le modèle de vue sont essentiellement des classes simples avec des attributs.

L'objectif principal de ces classes est de décrire (à «modéliser») un objet pour leurs publics respectifs qui sont respectivement le contrôleur et la vue.

Donc tu as tout à fait raison quand tu dis

À ma connaissance, c'est une sorte de modèle qui a pour but spécifique d'interagir avec la vue

Ainsi, alors que les classes de modèle sont effectivement des entités de domaine avec lesquelles votre application interagit, les modèles de vue sont des classes simples avec lesquelles vos vues interagissent.

J'espère que ça aide :)

Mise à jour :

Microsoft a développé une version spécialisée du Presentation Pattern de Martin fowler en grande partie basée sur le Model-View-Controller et l'a appelé Model-View-ViewModel (MVVM) pour l'application PF. Ce modèle est destiné aux plates-formes de développement d'interface utilisateur modernes où les développeurs d'interface utilisateur ont des exigences différentes basées davantage sur la logique métier que les développeurs traditionnels. Jetez un œil ici pour un peu de théorie

Dans le plus simple des termes, j'aime penser à ce qui suit:

Modèle: ressemble et ressemble strictement à votre modèle de données. À toutes fins utiles, il ne s'agit que d'une représentation de classe de votre modèle de données. Il n'a aucune connaissance de votre vue ou de tout élément de votre vue. Cela dit, il ne doit contenir aucun décorateur d'attribut (c'est-à-dire obligatoire, longueur, etc.) que vous utiliseriez pour votre vue.

Modèle de vue: sert de liant de données entre votre vue et votre modèle et, dans de nombreux cas, est également un wrapper pour votre modèle. Il serait rendu inutile sans la vue, de sorte qu'il n'est généralement pas réutilisable sur plusieurs vues et contrôleurs comme un modèle standard.

Par exemple, votre modèle peut avoir les propriétés suivantes, qui sont des représentations directes de votre source de données:

    public string FirstName { get; set; }
    public string LastName { get; set; }

Maintenant, puisque votre modèle de vue est lié à votre vue, il peut avoir la propriété suivante - qui concatène le champ FirstName et le champ LastName du modèle en une seule chaîne:

    [Display(Name = "Customer Name")]                
    public string CustomerFullName { get { return String.Format("{0} {1}", myModel.FirstName, myModel.LastName) }}

J'ai trouvé cet article une ressource très utile pour comprendre comment le «modèle de domaine» et le «modèle de vue» interagissent dans une application MVC, en particulier en ce qui concerne la liaison. Le meilleur de tous inclut des exemples au lieu de descriptions abstraites.

"Depuis que MVC a été publié, j'ai observé une grande confusion sur la meilleure façon de construire des modèles de vue. Parfois, cette confusion n'est pas sans raison car il ne semble pas y avoir une tonne d'informations sur les recommandations de bonnes pratiques. De plus, il n'y a pas une solution "taille unique" qui fait office de solution miracle. Dans cet article, je décrirai quelques-uns des principaux modèles qui ont émergé et les avantages / inconvénients de chacun. Il est important de noter que bon nombre de ces modèles ont émergé de personnes résolvant des problèmes du monde réel. "

http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx

WikiPedia a une description plus complète de Model vs ModelView que celle que vous obtiendrez dans une réponse SO: http://en.wikipedia.org/wiki/Model_View_ViewModel

Je cite:

Modèle : comme dans le modèle MVC classique, le modèle se réfère à (a) un modèle d'objet qui représente le contenu réel de l' état (une approche orientée objet), ou (b) la couche d'accès aux données qui représentent que le contenu (a Data- approche centrée).

Vue : comme dans le modèle MVC classique, la vue fait référence à tous les éléments affichés par l'interface graphique tels que les boutons, les fenêtres, les graphiques et autres contrôles.

ViewModel : le ViewModel est un «modèle de la vue» ce qui signifie qu'il s'agit d'une abstraction de la vue qui sert également à la liaison de données entre la vue et le modèle. Cela pourrait être considéré comme un aspect spécialisé de ce que serait un contrôleur (dans le modèle MVC) qui agit comme un classeur / convertisseur de données qui change les informations du modèle en informations de vue et transmet les commandes de la vue au modèle. Le ViewModel expose les propriétés publiques, les commandes et les abstractions. Le ViewModel a été comparé à un état conceptuel des données par opposition à l'état réel des données dans le modèle.

Il existe une notion de ViewModel, mais il n'est généralement pas associé à Asp.net MVC. MVC utilise le modèle Model View Controller, dans lequel le contrôleur gère les interactions, génère des données à partir du modèle, puis transmet ces données à la vue pour affichage.

ViewModels (et le modèle ViewModel Model View) est plus généralement associé à Silverlight et WPF. Xaml est un peu différent en ce que les vues peuvent faire une liaison bidirectionnelle avec les ViewModels, donc la technologie est un peu différente. Par exemple, si vous liez une zone de texte à un champ, à mesure que vous tapez dans cette zone de texte, la valeur du champ est mise à jour dynamiquement. Ce type d'interaction n'est pas vraiment possible dans les pages Web, car les pages Web sont sans état.

La similitude des deux modèles est qu'ils essaient tous deux de séparer la logique de l'affichage. L'utilisation / la raison la plus courante en est le test: vous voulez être en mesure d'effectuer à partir du code (via un framework de test) toutes les interactions qu'un utilisateur appellera via l'interface utilisateur.