Quelle approche choisir pour ViewModels?

Question

J'utilise ViewModels avec asp.net MVC3. Une des choses que je suis curieux est de supposer que j'ai une entité nommée Customers et qu'elle a des écrans Add, Edit, Delete. Supposons qu'ils ont tous des propriétés différentes.

Par exemple. Ajouter peut avoir un champ d'adresse mais l'écran d'édition n'a peut-être pas d'écran d'édition, la suppression peut uniquement utiliser le nom du client plus que toute autre chose.

Ma question est, comment créez-vous ViewModels pour cela? Allez-vous avec l'approche des ViewModels partagés entre ajouter, modifier et supprimer i.e une seule classe viewmodel qui gère tout pour vous ou préférez-vous créer des classes/page viewmodels? Avantage avec viewmodel partagé: cela réduit le temps de développement et nous pouvons réutiliser les classes. Mais le gros problème avec ceci est que si vous utilisez un outil comme Automapper vous pouvez vous attendre à des résultats pour différents écrans.

Inconvénient avec un seul viewmodel/page est qu'il augmente le temps de développement. Dans quel sens devrais-je aller?

Answer 1

Mon approche pour voir les modèles est d'utiliser des modèles de vue partagé jusqu'à ce que les exigences (la données transportées) à la vue est différente. Cela signifie que j'utilise un modèle de vue partagé par exemple pour CreateAddress et EditAddress dans le cas où toutes les données transportées vers la vue sont identiques. Dans le cas où un champ supplémentaire doit être affiché dans la vue, par exemple dans la vue CreateAddress, je suis en train de refactoriser mes modèles de vue et d'utiliser différents modèles de vue pour CreateAddress et EditAddress. Par exemple, pour DeleteAddress, j'utiliserais un modèle de vue distinct depuis le début car je sais que les données affichées dans la vue DeleteAddress ne sont presque jamais les mêmes que dans Create/EditAddress. Une autre approche consiste à utiliser des modèles de vue dynamique, puisque les modèles de vue doivent/ne doivent pas implémenter la logique métier et agir comme des DTO entre le contrôleur et voir cette approche présente des avantages (pas besoin de créer de logique, jeter les DTO).

Answer 2

Cela dépend de la situation. Si vous avez des exigences similaires pour différents écrans (validation, propriétés à afficher, etc.), vous pouvez utiliser le viewmodel sur différentes vues. S'il y a une différence d'une ou deux propriétés, j'utiliserais toujours le même viewmodel et là où ces propriétés ne sont pas nécessaires je les mettrai dans des entrées cachées afin qu'elles reviennent avec le post de formulaire ne permettant pas de résultats indésirables. Les champs cachés, comme tout le monde le sait, peuvent être modifiés et c'est au développeur de décider s'il est sécuritaire d'utiliser des champs cachés. Cependant, si j'ai des exigences de validation différentes pour deux écrans alors je dois absolument aller avec l'approche viewmodel/page. Vous pouvez mélanger les deux approches en fonction des besoins comme ils disent « il n'y a pas meilleure façon de faire les choses »

Answer 3

ViewModel Best Practices

ASP.NET MVC View Model Patterns

Answer 4

Tous les champs existant dans un modèle peuvent être modifiés. Peu importe s'ils sont cachés ou non. Tout ce que l'utilisateur a à faire est d'inspecter vos pages et d'essayer de comprendre quels champs existent dans le modèle. Puis il peut ajouter ces champs (par exemple avec Chrome Dev Tools) pour y apporter des modifications.

Le moyen le plus sûr de se débarrasser de ce problème consiste à utiliser uniquement des modèles dont les champs peuvent être modifiés. Cela dit, allez-y et utilisez le même modèle si tous les champs du modèle doivent être autorisés à être modifiés par tous les utilisateurs.(Et ne montrez simplement pas les champs qui ne devraient pas être modifiés)