ASP.NET MVC: utiliser les entités EF comme viewmodels?

Question

Possible en double:
ASP.NET MVC - Linq to Entities model as the ViewModel - is this good practice?

Est est OK d'utiliser des classes d'entités EF en tant que modèles d'affichage dans ASP.NET MVC? Que se passe-t-il si viewmodel est identique à 90% à la classe d'entité EF?

Disons que j'ai une classe Survey dans le modèle Entity Framework. Il correspond à 90% des données nécessaires à la vue pour l'éditer. La seule différence par rapport au modèle de vue doit être une ou plusieurs propriétés à utiliser (qui doivent remplir l'objet Survey car la classe EF ne peut pas être mappée directement sur la façon dont ses propriétés sont représentées (sous-cases à cocher, groupes radio, etc.))

Les transmettez-vous en utilisant ViewData []? Ou créez une copie de la classe Survey (SurveyViewModel) avec de nouvelles propriétés supplémentaires (il devrait être en mesure de copier les données de Survey et de revenir à celles-ci)?

Modifier: J'essaie également d'éviter d'utiliser Survey en tant que propriété SurveyViewModel. Il semblera étrange lorsque certaines propriétés de Survey sont mises à jour à l'aide de UpdateModel ou du classeur par défaut, tandis que d'autres (qui ne peuvent pas être mappées directement à l'entité) utilisent les propriétés personnalisées de SurveViewModel dans le contrôleur.

Answer 1

J'aime utiliser Jimmy Bogard's approach de toujours avoir une relation 1: 1 entre une vue et un modèle de vue. En d'autres termes, je n'utiliserais pas mes modèles de domaine (dans ce cas, vos entités EF) comme modèles de vue. Si vous sentez que vous faites beaucoup de travail de cartographie entre les deux, vous pouvez utiliser quelque chose comme AutoMapper pour faire le travail pour vous.

Answer 2

Sur les projets plus volumineux, je divise généralement les objets métier à partir d'objets de données en termes de style. C'est un moyen beaucoup plus simple de laisser le programme et la base de données changer et n'affecter que la couche de contrôle (ou machine virtuelle).

Answer 3

Certaines personnes n'aiment pas transmettre ces classes de modèles jusqu'à la vue, en particulier parce qu'elles sont liées à l'ORM particulier que vous utilisez actuellement. Cela signifie que vous liez étroitement votre infrastructure de données à vos types de vue.

Cependant, je l'ai fait dans plusieurs applications MVC simples, en utilisant le type d'entité EF comme modèle pour certaines vues fortement typées - cela fonctionne très bien et est très simple. Parfois, des gains simples suffisent, sinon vous risquez de devoir déployer beaucoup d'efforts et de code pour copier des valeurs entre des types de modèles quasiment identiques dans une application où, de manière réaliste, vous ne vous éloignez jamais de EF.

Answer 4

Vous devez toujours avoir des modèles de vue même s'ils sont 1: 1. Il y a des raisons pratiques plutôt que le couplage de la couche de base de données sur lequel je vais me concentrer. Le problème avec les modèles de domaine, de framework d'entité, de nhibernate ou de linq 2 sql comme classes d'affichage est que vous ne pouvez pas bien gérer la validation contextuelle.Par exemple donné une classe d'utilisateurs:

Lorsqu'une personne signe sur votre site, ils obtiennent un écran d'utilisateur, vous alors:

1. Valider Nom
2. Valider Email
3. Valider Mot de passe EXISTE

Lorsqu'un administrateur modifie le nom d'un utilisateur, il obtient un écran Utilisateur, puis:

1. Valider Nom
2. Valider Email

maintenant la validation contextuelle via exposer FluentValidation, DataAnnotations attributs, ou même des méthodes IsValid personnalisées() sur les classes d'affaires et de valider uniquement le nom et les changements E-mail. Tu ne peux pas. Vous devez représenter différents contextes en tant que modèles de vue différents, car la validation de ces modèles change en fonction de la représentation à l'écran.

Précédemment dans MVC 1, vous pouviez contourner ce problème en postant simplement les champs que vous ne vouliez pas valider. Dans MVC 2, cela a changé et maintenant chaque partie d'un modèle est validée, affichée ou non.

---

Robert Harvey a souligné un autre bon point. Comment votre utilisateur Entity Framework affiche-t-il un écran et valide-t-il le double mot de passe?