ASP.NET MVC - exactement Comment utiliser des Modèles de Vue

Disons que j'ai une page qui permet l'édition d'un utilisateur de détails, j'ai donc un ViewModel comme ceci:

public class UserViewModel {
    public string Username { get; set; }
    public string Password { get; set; }
    public int ManagerId { get; set; }
    public string Category { get; set; }
}

Donc sur mon EditUser action que je peux avoir cette passé par le modèle de classeur et puis je peux la carte que pour le Modèle de Domaine:

public ActionResult EditUser(UserViewModel user) {
    ...

Néanmoins, la page qui affiche le formulaire doit également des détails tels qu'une liste des Gestionnaires et des Catégories de fournir des listes déroulantes pour ces champs. Il peut également afficher une liste des autres utilisateurs dans une barre latérale de sorte que vous pouvez basculer entre les différents utilisateurs du montage.

Donc, puis-je avoir un autre point de vue modèle:

public class ViewUserViewModel {
    public UserViewModel EditingUser { get; set; }
    public IEnumerable<SelectListItem> Managers { get; set; }
    public IEnumerable<SelectListItem> Categories { get; set; }
    public IEnumerable<SelectListItem> AllUsers { get; set; }
}

Est-ce la bonne façon de le faire? Sont-ils à la fois les Modèles de Vue? Si oui, est-il une convention de nommage que je devrais utiliser afin que je puisse distinguer entre les machines virtuelles qui sont comme les modèles et les machines virtuelles qui ne contiennent que les données de la page?

Ai-je eu ce tort et à travers?

InformationsquelleAutor littlecharva | 2013-05-14

asp.net-mvc viewmodel

Comment je le faire en raccourci:

Créer des ViewModel de la classe pour chaque formulaire sur la page, puis j'ai rendu ces classes avec PartialViews comme @{Html.RenderPartial("PartialName", Model.PartialModel);}.
Si la page contient des choses comme le html metas je fais séparés de classe pour les metas et le mettre dans la section sur la page.
Reste des cas comme "dois-je mettre cela dans des locaux séparés de la classe?", c'est votre jugement.

Ainsi, par exemple, vous avez la page qui a une sorte de connexion/s'inscrire bar ou un pop-up que ce soit.

public class SomePageViewModel
{
public RegisterBarVM Register { get; set; }
public LoginBarVM LoginBar { get; set; }
public MetasVM Metas { get; set; }
public string MaybePageTitle { get; set;}
public string MaybePageContent { get; set;}
[HiddenInput(DisplayValue = false)]
public int IdIfNeeded { get; set; }
public IEnumerable<SelectListItem> SomeItems {get; set;}
public string PickedItemId { get;set; }
}
public class RegisterBarVM
{
public string RegisterUsername {get;set;}
public string RegisterPassword {get;set;}
//...
}
public class LoginBarVM
{
public string LoginUserame {get;set;}
public string LoginPassword {get;set;}
//...
}
//cshtml
@model yourClassesNamespace.SomePageViewModel
@{
Html.RenderPartial("LoginBar", Model.LoginBar); //form inside
Html.RenderPartial("RegisterBar", Model.RegisterBar); //form inside
using(Html.BeginForm())
{
@Html.EditorFor(m => m.IdIfNeeded)
@Hmtl.EditorFor(m => m.MaybePageTitle)
@Hmtl.EditorFor(m => m.MaybePageContent)
@Hmtl.DropDownListFor(m => m.PickedItemId, new SelectList(Model.SomeItems))
<input type="submit" value="Update" />
}
}
@section Metas {
@{Html.RenderPartial("Meatas", Model.Metas}
}

À propos de l'éditeur de modèles de Brad Wilson Blog et simplement google ou chercher des piles de ressources à propos de l'affichage/l'éditeur de modèles et HtmlHelpers. Elles sont toutes très utiles pour la construction cohérente des sites web.

InformationsquelleAutor Mariusz

94

"Modèle de vue" n'est qu'un modèle. Il n'y a rien de magique dans le nom, mais en général, toute la classe qui est passé à un point de vue (que ce soit pour un simple affichage des données ou à des fins de soumissions de formulaire) est désigné comme un "modèle de vue" et donné un nom comme FooViewModel ou FooVM pour indiquer qu'il fait partie de cette "vue" de modèle de modèle.

Je ne veux pas aller trop philosophique sur vous, mais je crois qu'un peu de référence sur les modèles dans le jeu sera utile. ASP.NET MVC évidemment assez encourage un MVC (Modèle-Vue-Contrôleur) modèle architectural. Dans MVC le Modèle de conteneur pour l'application de l' logique d'entreprise. Le Contrôleur est responsable du traitement de la demande, d'aller chercher le modèle, le rendu de la Vue avec ce modèle et de renvoyer une réponse. Cela ressemble à beaucoup de responsabilité mais en réalité, le cadre assure la plus grande partie de derrière les coulisses, les Contrôleurs sont généralement (et devraient) être très clair sur le code. Ils sont responsables pour le minimum de fonctionnalités au fil de tout ce. Enfin, il est responsable de la création de la couche d'INTERFACE utilisateur qui permet à l'utilisateur d'interagir avec les données dans le Modèle. Il est pas responsable de la donnée elle-même, ni ne devrait être (ViewData/ViewBag est un assez gros violation d'ici, au moins autant que la façon dont il finit par être utilisé par les développeurs dans la pratique).

Donc, cela signifie que la majeure partie de la logique de l'application devrait être dans votre modèle, et qui est généralement une bonne chose. Toutefois, étant donné que le modèle est le havre de données de l'application, il obtient généralement persisté dans une base de données ou similaire. Qui crée des conflits d'intérêts que vous devez maintenant commencer à un équilibre entre ce que les données doivent être conservées et que les données ne devrait exister que pour la fin de l'affichage.

C'est là que les modèles de vue venir. MVVM (Model-View-Vue Modèle), un peu parallèle pattern MVC, reconnaît les problèmes inhérents à un modèle-à-règle-them-all approche. Je n'entrerai pas dans les détails ici, car MVC ne pas utiliser ce modèle. Cependant, la plupart des ASP.NET MVC développeurs ont coopté le Modèle de Vue de MVVM. Ce que vous retrouvez avec une base de données adossés à des entité (le modèle traditionnel) et puis, généralement, plusieurs modèles de vue qui représentent cette entité dans divers états. Cela permet à votre modèle pour contenir la logique d'entreprise qui est pertinent pour la persistance, tandis que le modèle de vue(s) contiennent la logique métier pertinents pour l'affichage, la création et la mise à jour de ce modèle.

J'ai dû abandonner un peu, mais le long et court, c'est que ce que vous faites est tout à fait acceptable. En fait, c'est une bonne pratique. Créer autant de modèles de vue que votre application a besoin, et de les utiliser pour stocker les données et la logique métier nécessaire pour votre point de vue. (Qui inclut des choses comme SelectLists. Ni votre contrôleur ni vue devriez avoir besoin de savoir comment créer un SelectList pour une liste déroulante.)
- La meilleure explication à propos de ce sujet. Vous pouvez le mettre sur un Blog! +1
- Vous avez mentionné les modèles devraient être responsables de la logique métier de l'application. En affaires, vous avez sans doute dire toutes les données de la préparation, de l'interrogation, le filtrage, la projection d'un modèle à l'autre, ou d'un ViewModel. Et puis ces préparé ViewModel est passé à Vue par le contrôleur. Comment avez-vous physiquement le faire? Comment concevoir des modèles dans le but de faire de l'entreprise? Avez-vous par exemple de déplacer tous les contrôleurs de méthodes de classes représentant les modèles de vue? Actuellement, j'ai beaucoup de fonctions et de "business" dans les contrôleurs qui ne tous les bits et les boulons. merci
- Franchement, vous ne pouvez pas vraiment dans ASP.NET MVC. Pour vraiment comprendre de quoi je parle, construire un exemple d'application en Ruby on Rails. RoR respecte le modèle MVC très strictement, et vous verrez exactement combien va dans leurs modèles. ASP.NET MVC, sur l'autre main ne lâche adhère à la MVC. Vous "Modèle" seront une combinaison de classes d'entités, les modèles de vue, et quelque chose comme un référentiel ou d'un service. Vous devriez essayer de toujours garder vos contrôleurs mince, vous ne pouvez pas déplacer tous la logique dans une classe.
InformationsquelleAutor Chris Pratt
9

Personnellement, je préfère mettre toutes les informations nécessaires pour le rendu de la page dans le ViewModel, comme c'est le but de ce Dernier à fournir toutes les données de la Vue. Donc, mon UserViewModel serait contiennent des propriétés de Managers, Categories et AllUsers et le contrôleur de remplir ces collections d'avant le passage de ce Dernier à la vue.

C'est essentiellement ce que vous avez fait - il supprime juste les extra ViewModel à partir de l'équation.

J'ai aussi vu d'autres programmeurs utilisent le ViewData pour envoyer les listes déroulantes de la vue, mais je n'aime pas que parce que ViewData n'est pas fortement typé, alors qu'un ViewModel est.

InformationsquelleAutor Jason Berkan

Vous devez vous connecter pour publier un commentaire.