Modèle ASP.NET MVC vs ViewModel

OK, j’ai entendu parler de “ViewModels” en ce qui concerne ASP.NET MVC de MS.

Maintenant, cela est destiné à être un type spécifique de modèle, correct? Pas un type spécifique de vue.

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

Une clarification serait appréciée.

Essentiellement, le modèle et le modèle de vue sont tous deux des classes simples avec des atsortingbuts.

L’objective principal de ces classes est de décrire (pour “modéliser”) un object pour leurs audiences respectives qui sont respectivement le contrôleur et la vue.

Donc tu as complètement raison quand tu dis

A ma connaissance, c’est une sorte de modèle qui a un 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 cela 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 Model-View-Controller et l’a appelée Model-View-ViewModel (MVVM) pour application PF. Ce modèle est destiné aux plates-formes de développement d’interface utilisateur modernes pour lesquelles les développeurs d’interfaces utilisateur ont des besoins différents, plus basés sur la logique métier que les développeurs traditionnels. Regardez ici un peu de théorie

En termes simples, j’aime penser à ce qui suit:

Modèle: Ssortingctement ressemble et ressemble à 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 d’éléments dans votre vue. Cela dit, il ne devrait pas contenir de décorateurs d’atsortingbuts (c.-à-d. Requis, longueur, etc.) que vous utiliseriez pour votre vue.

Modèle de vue: sert de classeur de données entre votre vue et votre modèle et, dans de nombreux cas, est également une enveloppe 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, 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 ssortingng FirstName { get; set; } public ssortingng LastName { get; set; } 

Maintenant, votre modèle de vue étant lié à votre vue, il peut avoir la propriété suivante – qui concatène le champ Prénom du modèle et le champ Nom comme une seule chaîne:

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

J’ai trouvé cet article 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 la publication de MVC, j’ai constaté une grande confusion quant à la meilleure façon de construire des modèles de vue. Parfois, cette confusion n’est pas sans fondement car il ne semble pas y avoir beaucoup d’informations sur les meilleures pratiques. une solution unique qui représente la solution miracle Dans cet article, je décrirai quelques-uns des principaux modèles qui se sont dégagés et les avantages et inconvénients de chacun. 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 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 fait référence à (a) un modèle d’object représentant le contenu de l’état réel (approche orientée object) ou (b) la couche d’access aux données qui représente ce contenu (une firebase database). approche centrée).

Afficher : 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, fenêtres, 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 lieur / convertisseur de données qui modifie les informations du modèle dans les informations de vue et transmet les commandes de la vue au modèle. ViewModel expose les propriétés publiques, les commandes et les abstractions. ViewModel a été assimilé à un état conceptuel des données, par opposition à l’état réel des données du modèle.

Il existe une notion de ViewModel, mais elle n’est généralement pas associée à Asp.net MVC. MVC utilise le modèle de contrôleur de vue de modèle, dans lequel le contrôleur gère les interactions, crée des données à partir du modèle, puis transmet ces données à la vue pour les afficher.

ViewModels (et le modèle ViewModel de la vue Modèle) est plus généralement associé à Silverlight et à WPF. Xaml est un peu différent en ce sens que les vues peuvent se lier de manière bidirectionnelle aux ViewModels, de sorte que la technologie est un peu différente. Par exemple, si vous liez une zone de texte à un champ, lorsque vous tapez dans cette zone de texte, la valeur du champ est mise à jour de manière dynamic. Ce type d’interaction n’est pas vraiment possible dans les pages Web, car les pages Web sont sans état.

La similitude dans les deux modèles est qu’ils essaient tous deux de séparer la logique de l’affichage. L’utilisation / la raison la plus courante est le test: vous voulez pouvoir effectuer à partir du code (via un framework de test) toutes les interactions qu’un utilisateur invoquera via l’interface utilisateur.