Quelle est la granularité appropriée dans la construction d'un ViewModel?

Question

Je travaille sur un nouveau projet, et, après avoir vu certaines des difficultés des projets antérieurs qui ne fournissaient pas assez de séparation de vue de leurs modèles (en particulier en utilisant MVC - les modèles et les vues ont commencé à se réduire un peu), Je voulais utiliser MVVM.

Je comprends le concept de base, et je suis ravi de commencer à l'utiliser. Cependant, une chose qui m'échappe un peu - quelles données devraient être contenues dans le ViewModel?

Par exemple, si je crée un ViewModel qui comprendra deux éléments de données afin qu'ils puissent être éditées sous une forme, puis-je capturer comme ceci:

public PersonAddressViewModel { 
    public Person Person { get; set; } 
    public Address Address { get; set; } 
} 

ou comme ceci:

public PersonAddressViewModel { 
    public string FirstName { get; set; } 
    public string LastName { get; set; } 
    public string StreetName { get; set; } 
    // ...etc 
} 

Pour moi, le premier se sent plus correct pour ce que nous essayons de faire. Si nous faisions plus de formes de grains fins (peut-être que tout ce que nous capturions était FirstName, LastName, et StreetAddress), alors il serait plus logique de descendre à ce niveau. Mais, j'ai l'impression que le premier est correct puisque nous capturons TOUTES les données de la personne dans le formulaire et toutes les données d'adresse. Il semble que cela n'a pas de sens (et beaucoup de travail supplémentaire) de séparer les choses comme ça.

Appréciez tout aperçu.

Answer 1

Si vous utilisez tous les champs de l'objet Personne, il n'y a rien de mal à utiliser un modèle de vue complexe. Cependant, si vous n'utilisez qu'un champ ici ou là, il vaut mieux construire votre viewmodel avec seulement les valeurs que vous utilisez.

Vous pouvez faire vos modèles de vue comme vous le souhaitez, mais le but est de les personnaliser en fonction de la vue qu'ils représentent.

Il peut également être beaucoup plus facile d'utiliser la première méthode si vous utilisez quelque chose comme AutoMapper pour mapper des modèles métier ou de domaine, car les objets doivent avoir des définitions similaires.

Answer 2

Si vous utilisez ce modèle pour afficher un formulaire, je voterais pour la deuxième approche, puisque vous combinez toutes les données d'affichage requises pour le formulaire.

Answer 3

Vous n'utilisez pas MVVM. Vous définissez ViewModels, classes à des fins de visualisation uniquement afin d'éviter de casser les classes Model. Dans ce cas, vous pouvez définir les propriétés que vous voulez pour votre meilleur profit. Dans l'exemple, je vais opter pour la deuxième solution, mais c'est à vous de décider.

Je travaille sur un grand projet avec de nombreux développeurs de développeurs. Dans ce cas, le client nous a laissé définir les ViewModels que nous souhaitons conserver pour les préoccupations des modèles (entités commerciales comme ils appellent). Parce que nous sommes différents groupes personne ne s'inquiète d'un autre ViewModels, vous pouvez même utiliser une classe pour une vue, peu importe si une autre vue est différente de la première. C'est l'un des avantages de ViewModels au lieu de l'utilisation pure de Model.

Je préfère définir les ViewModels dans les objets JSON côté client par souci de liaison de données. Avec cela, vous pouvez vraiment utiliser MVVM à travers knockoutjs, angularjs, backbonejs, etc ....

Si vous voulez utiliser MVVM vérifier knockoutjs. Il est très facile et agréable à utiliser

Answer 4

L'utilisation directe de classes Model ou leur emballage (comme dans votre 1er exemple) dans votre classe ViewModel peut poser un problème de sécurité potentiel si vos classes Model ont des propriétés sensibles (par exemple,IsAdmin dans la classe User).

Dites vos actions de contrôleur prend un paramètre d'entrée PersonAddressViewModel:

public ViewResult someAction(PersonAddressViewModel personAddress) 
{ 
    //save it 
} 

Un utilisateur malveillant peut essentiellement définir des propriétés dans votre objet composite PersonAddressViewModel même si votre interface utilisateur ne fournit pas ces capabilitiy. Ceci est rendu possible par le mécanisme de liaison par défaut du MVC. Pour éviter cela, ne pas envelopper les classes de modèles sensibles ou utiliser le Bind attribute

Plus sur cette ici: Pro ASP.NET MVC 3 Framework 3rd Edition By Steven Sanderson , Adam Freeman (chapitre 17)