asp.net mvc - presque identiques ViewModels

Question

Je construis une application web avec ASP.NET MVC et je suis encore un débutant avec cette technologie.

J'ai appris qu'il est préférable d'avoir un ViewModel pour chaque vue. Je peux comprendre pourquoi c'est une bonne idée. Cependant, dans ma situation, cela semble créer beaucoup de travail supplémentaire.

J'ai un modèle appelé Rule. Il contient un ID, un titre, une description, LastModifiedDate, CreatedDate, entre autres champs.

J'ai une vue Modifier, Créer et Détails pour le modèle de règle. Selon la meilleure pratique, je dois créer un ViewModel pour chacune des vues ci-dessus.

Mais les ViewModels pour les vues ci-dessus sont presque identiques. L'une des seules différences est que le Create-ViewModel n'a pas d'ID, mais que DetailsModels et Modifications le font. A part ça, les ViewModels sont presque identiques. Autrement dit, ils contiennent les mêmes attributs et les mêmes champs de validation DataAnnotation. Pourquoi est-ce que je pense que c'est gênant? Supposons que je souhaite modifier certaines des annotations de données. Par exemple. chaneg une longueur maximale d'un attribut de chaîne. Si je souhaite le faire, je dois le faire à la fois dans le modèle de règle, le Create ViewModel et Edit ViewModel. Et de même si je souhaite ajouter de nouveaux attributs, je dois le faire dans tous les modèles. Est-ce que je le fais bien, ou peut-il être simplifié?

Answer 1

Eh bien, il s'agit plus d'une décision d'implémentation que d'une règle de meilleure pratique.Vous devez prendre en compte quelques-uns des avantages et des inconvénients:

différents ViewModel pour chaque vue

• Modifier seulement le ViewModel associé à la vue
• Flexibilité
• difficile à maintenir très grandes applications

Réutiliser ViewModels pour différents affichages

• Modifier tous les ViewModels à la fois
• beaucoup plus facile à maintenir
• flexibilité limitée

Mon conseil serait de créer la RuleViewModel de base sans la propriété ID et pour la modifier et les détails Les actions héritent du modèle et ajoutent la colonne supplémentaire.

Answer 2

Ce n'est jamais une règle de faire ViewModel per View. Tout dépend de la façon dont votre architecture est. Selon votre condition si vous sentez que les deux vues sont exactement identiques alors utilisez le même ViewModel.

IMO n'utilise pas d'annotation de données, si possible, optez pour Fluent Api.

Answer 3

Pour toutes les opérations: ajouter, mettre à jour, supprimer - vous pouvez utiliser un modèle de vue - Rule. C'est très bien que vous voulez manipuler avec cet objet unique, non?

La seule différence serait l'affichage de plusieurs Rule objets - Liste page vue, ici, vous voudrez peut-être créer un viewmodel supplémentaire comme RuleListViewModel qui contiendra une collection (IEnumerable<Rule>) d'objets et peut-être quelques propriétés pour le filtrage, etc. sur.

Answer 4

Il semble que vous mélangez vos modèles de vue et vos objets de gestion. En général, j'essaie de les séparer car ils servent différents objectifs.

Votre objet métier peut avoir des méthodes CRUD. Votre modèle de vue peut avoir une propriété qui expose votre objet et peut en fait exposer d'autres objets si nécessaire.

En procédant ainsi, vous préservez la règle de l'utilisation unique et la maintenez très facilement. Mais, c'est vraiment un choix de conception plutôt que des «meilleures pratiques» qui (soyons honnêtes) changent avec le vent.