ASP.NET MVC Model vs ViewModel

OK, j'ai entendu parler de "Modèles de vue" en ce qui concerne les ASP.NET MVC.

maintenant, c'est un modèle spécifique, non? Pas un type spécifique de Vue.

pour moi, c'est une sorte de modèle qui a un but précis d'interagir avec la vue? Ou quelque chose comme ça?

des précisions seraient les bienvenues.

78
demandé sur Qcom 2010-10-31 04:21:55

5 réponses

essentiellement Model et View Model sont deux 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 vous avez tout à fait raison quand vous dites

à mon avis, c'est une sorte de Modèle qui a un but précis de interagir avec la vue

donc, alors que les classes modèles 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.

Espère que cela aide :)

mise à Jour :

Microsoft a développé une version spécialisée du modèle de présentation par Martin fowler largement basé sur le modèle-View-Controller et appelé it Model-View-ViewModel (MVVM) for PF application. Ce modèle est destiné aux plates-formes modernes de développement D'UI où les développeurs D'UI ont des exigences différentes basées plus sur la logique d'affaires que les développeurs traditionnels. Avoir un regard ici pour un peu de théorie

57
répondu Lorenzo 2010-10-31 01:42:00

dans les termes les plus simples, j'aime penser à ce qui suit:

modèle: ressemble strictement et se sent comme votre modèle de données. Pour toutes fins utiles, il est seulement une représentation de classe de votre modèle de données. Il n'a aucune connaissance de votre point de vue ou de tout élément de votre point de vue. Cela dit, il ne devrait pas contenir d'attribut décorateurs (c.-à-d. requis, longueur, etc.) que vous pouvez utiliser pour votre point de Vue.

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

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é pour votre vue, il peut avoir la propriété suivante-qui concaténate le champ FirstName du Model et le champ LastName ensemble comme une chaîne de caractères:

    [Display(Name = "Customer Name")]                
    public string CustomerFullName { get { return String.Format("{0} {1}", myModel.FirstName, myModel.LastName) }}
53
répondu Jason Marsell 2013-09-14 23:24:26

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 au sein d'une application MVC, particulièrement en ce qui concerne la liaison. Le meilleur de tous comprend des exemples plutôt que des descriptions abstraites.

" depuis que MVC a été libéré, j'ai observé beaucoup de confusion sur la meilleure façon de construire des modèles de vue. Parfois, cette confusion n'est pas sans bonne raison, puisqu'il ne semble pas être une tonne d'informations sur les recommandations des meilleures pratiques. De plus, il n'existe pas de solution unique qui joue le rôle de solution miracle. Dans ce post, je vais décrire 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é des gens qui résolvent des problèmes du monde réel."

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

24
répondu misteraidan 2011-05-03 01:50:49

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

je cite:

Model : comme dans le modèle classique MVC, le modèle se réfère soit (a) à un modèle d'objet qui représente le contenu réel (une approche orientée objet), ou (B) à la couche d'accès aux données qui représente ce contenu (a centrée sur les données de l'approche).

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

ViewModel : le ViewModel est un "modèle de la vue" ce qui signifie qu'il est une abstraction de la vue qui sert également dans les données liant la vue et le modèle. Il pourrait être considéré comme un aspect spécialisé de ce qui serait une Contrôleur (dans le modèle MVC) qui agit comme un liant/convertisseur de données qui change l'information du modèle en information de vue et passe des commandes de la vue dans le modèle. Le ViewModel expose les propriétés publiques, les commandes et les abstractions. Ce Dernier a été comparé à un état conceptuel des données, par opposition à l'état réel des données dans le Modèle.

16
répondu Ian Mercer 2014-02-14 09:29:13

il existe une notion de modèle de vue, mais il n'est pas généralement associé à Asp.net MVC. MVC utilise le Model View Controller patter, où le controller gère les interactions, accumule les données du Model, puis les transmet à la View pour affichage.

Viewmodel (et le Model View ViewModel pattern) est plus généralement associée avec Silverlight et WPF. Xaml est un peu différent en ce que les vues peuvent se lier dans les deux sens aux modèles de vue, de sorte que le la technologie est un peu différent. Par exemple, si vous liez une boîte de texte à un champ, comme vous tapez dans cette boîte 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 apatrides.

la similitude entre les deux modèles est qu'ils essaient tous deux de séparer la logique de l'affichage. L'utilisation/raison la plus courante est testing: vous voulez être capable d'effectuer à partir du code (via un framework testing)) toutes les interactions qu'un utilisateur va invoquer via L'Interface utilisateur.

5
répondu Travis 2010-10-31 01:48:55