Modèle ASP.NET MVC et ViewModel
OK, j'ai entendu parler de "ViewModels" en ce qui concerne ASP.NET MVC de MS.
Maintenant, cela est censé être un type spécifique de modèle, correct? Pas un type spécifique de vue.
À ma connaissance, il s’agit d’une sorte de modèle qui a un objectif spécifique d’interaction avec la vue? Ou quelque chose comme ça?
Des éclaircissements seraient appréciés.
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 audiences respectives qui sont respectivement le contrôleur et la vue.
Donc, vous avez tout à fait raison quand vous dites
À ma connaissance, il s’agit d’une sorte de modèle qui a pour objectif 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 de simples classes avec lesquelles vos vues interagissent.
J'espère que ça aide :)
Mise à jour :
Microsoft a développé une version spécialisée du modèle de présentation de Martin fowler largement basée sur le contrôleur modèle-vue-contrôleur et l'a appelée modèle-vue-vue (MVVM) pour 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 oeil ici pour un peu de théorie
Dans les termes les plus simples, j'aime penser à ce qui suit:
Model: ressemble strictement à votre modèle de données. À toutes fins utiles, il ne s'agit que d'une représentation en classe de votre modèle de données. Il n'a aucune connaissance de votre vue ni d'éléments dans votre vue. Cela dit, il ne doit contenir aucun attribut décorateur (c.-à-d. Obligatoire, Longueur, etc.) que vous utiliseriez pour votre vue.
View Model: Sert de liant de données entre votre vue et votre modèle et, dans de nombreux cas, constitue également un wrapper pour votre modèle. Il serait rendu inutilisable sans la vue. Par conséquent, il n'est généralement pas réutilisable entre plusieurs vues et contrôleurs, contrairement à 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; }
À présent, étant donné que votre modèle de vue est lié à votre vue, il peut avoir la propriété suivante, qui concatène ensemble les champs Prénom du modèle et Nom 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 au sein d'une application MVC, en particulier en ce qui concerne la liaison. Le meilleur de tous comprend des exemples au lieu de descriptions abstraites.
"Depuis la publication de MVC, j'ai constaté une grande confusion quant à la meilleure façon de construire des modèles de vues. Parfois, cette confusion n’est pas sans raison, car il ne semble pas y avoir une tonne d’informations à ce sujet. En outre, il n’existe pas de solution universelle qui fasse office de solution miracle. Dans cet article, je vais décrire quelques-uns des principaux schémas qui se sont dégagés et les avantages/inconvénients de chacun. Il est important de noter que bon nombre de ces schémas ont été créés par des 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 un SO answer: http://en.wikipedia.org/wiki/Model_View_ViewModel
Je cite:
Modèle : comme dans le modèle MVC classique, le modèle fait référence à (a) un modèle objet représentant le contenu de l'état réel (approche orientée objet). ), ou (b) la couche d’accès aux données qui représente ce contenu (approche centrée sur les données).
View : 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 servant également de liaison de données entre la vue et le modèle. . Cela pourrait être perçu comme un aspect spécialisé de ce que serait un contrôleur (dans le modèle MVC) agissant comme un classeur/convertisseur de données transformant les informations de modèle en informations de vue et en transmettant des commandes de la vue au modèle. ViewModel expose les propriétés publiques, les commandes et les abstractions. Le ViewModel a été assimilé à 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, crée des données à partir du modèle, puis les transmet à la vue pour affichage.
ViewModels (et le modèle Model View ViewModel) 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 aux ViewModels, donc la technologie est un peu différente. Par exemple, si vous liez une zone de texte à un champ lors de la saisie dans cette zone de texte, la valeur du champ est mise à jour de manière dynamique. Ce type d'interaction n'est pas vraiment possible dans les pages Web car celles-ci sont sans état.
La similitude entre les deux modèles est qu'ils essaient tous deux de séparer la logique de l'affichage. La raison la plus courante est le test: vous voulez pouvoir effectuer à partir de code (via un framework de test) toutes les interactions qu'un utilisateur invoquera via l'interface utilisateur.