ASP.NET MVC et ADO.NET Entity Framework

Question

J'ai un problème que je ne peux pas résoudre sans quelques conseils. Je développe une application ASP.NET MVC et j'utilise ADO.NET EF pour me connecter à la base de données. Mon problème est que je ne sais pas si la logique métier de mon application doit utiliser des entités créées par EF ou dois-je créer une couche d'abstraction supplémentaire et séparer les entités EF de mes objets logiques métier (et développer des convertisseurs entre ces types d'objet). Ou peut-être que je me trompe totalement et que je devrais le faire différemment? Comment? Quelle solution serait la meilleure pratique?

Answer 1

Cela dépend absolument de votre application, de sa portée et de ses exigences. Introduire des couches d'abstraction juste pour les couches signifie introduire de la complexité et de l'indirection, où souvent cela ne vous mène nulle part. Pour la surutilisation de l'architecture en couches le terme Lasagna Software est actuellement en cours d'introduction - en remplacement du tristement célèbre Spaghetti Software.

Pour être clair, je ne propose pas de couches d'abstraction. Leur utilisation dépend fortement de vos besoins spécifiques. Je commencerais par une architecture simple et ajouterais des couches si nécessaire pour assurer la testabilité et la maintenabilité. La version actuelle Entity Framework (4.1 de cette écriture) permet de travailler avec Poços et DbContext assez ressemble beaucoup à la Repository et Unité de travail modèles. Ces fonctionnalités prêtes à l'emploi peuvent être suffisantes pour démarrer dans la plupart des cas.

Answer 2

J'ai géré des situations comme celle-ci en ayant des projets séparés pour les classes de données et les classes de modèle. Les classes de données sont celles générées par votre modèle ADO.net, vous pouvez ensuite utiliser le modèle Repository pour vous connecter au contexte ADO.net, récupérer les classes de données et utiliser quelque chose comme http://automapper.codeplex.com/ pour mapper la classe de données au modèle d'affaires. Cela vous permettra d'utiliser la validation MVC telle que Required, Regex, etc. sur les modèles, et de ne pas jouer avec les classes Data, et de ne faire que contourner les modèles.

Answer 3

En général, je trouve préférable de placer la logique métier à la fois dans le modèle de domaine et dans une couche de service. La logique dans le modèle de domaine est préférable, car elle est plus facile à tester, mais toute la logique n'est pas facilement implémentée de cette manière. Par exemple. Lorsqu'une opération implique de nombreux objets de domaine, vous ne pouvez pas toujours la placer raisonnablement dans l'un d'entre eux sans conséquences sur les performances et autres problèmes.

Answer 4

C'est ici qu'interviennent les POCO. Vous pouvez générer des POCO génériques à partir de votre modèle de données et les utiliser dans votre couche de gestion. EF va ensuite créer des POCO et les suivre.

L'idée ici est que votre POCO de ne sont que des entités, et pas des objets EF (si EF fait, les coulisses créer des versions de proxies de votre POCO)