ASP.NET et Entity Framework dans une architecture en couches - utiliser Entity Framework pour l'ORM uniquement

Question

J'ai une application ASP.NET qui utilise une architecture en couches, c'est-à-dire une couche de présentation, une couche de logique commerciale et une couche d'accès aux données.

Je ne veux pas que la couche métier ait à connaître la façon dont la couche d'accès aux données est mise en œuvre et je ne cherche pas à lier les entités directement à un contrôle de données en utilisant l'EntityDataSource ou quelque chose de ce genre. (donc un scénario de type référentiel)

JE CHERCHE SIMPLEMENT À UTILISER LE CADRE D'ENTITÉS COMME UN OUTIL ORM POUR GÉNÉRER DES CLASSES. Je sais comment faire. Ce qui n'est pas clair pour moi, c'est

1. Est-il conseillé de propager ces classes dans l'application afin que la couche de logique métier traite les classes partielles créées directement par le cadre d'entité ? (par exemple, si j'ai une table de clients dans sql, le framework d'entité créera une classe de client qui pourrait potentiellement être utilisée directement dans toutes les couches de mon application).
2. Comment gérer la prise en charge des transactions si mon BLL appelle plusieurs classes d'entités différentes mais veut les traiter comme une seule transaction ?

Answer 1

1. Si vous êtes pratique : Oui ! Cela vous évitera le travail de double mapping et les erreurs potentielles générées par le double mapping. (Par double mappage, j'entends BD -> ORM et ORM -> logique métier).
2. Utilice TransactionScope . C'est la meilleure façon d'effectuer des transactions sans se soucier des transactions imbriquées.

Answer 2

Je pense que cela peut être la réponse à votre problème :

http://code.msdn.microsoft.com/EFPocoAdapter/Release/ProjectReleases.aspx?ReleaseId=1580

L'outil génère des classes qui ne dépendent pas du cadre d'entités et que vous pouvez faire passer d'un niveau à l'autre.

Answer 3

Une autre façon de procéder est d'utiliser des classes de mappeur, d'utiliser ce que EF a purement comme accès aux données et d'utiliser les classes EF générées uniquement dans le DAL, puis de mapper ces objets DAL aux objets de votre BLL par le biais de mappeurs. Cela fonctionne bien pour nous.

Answer 4

Désormais, avec le nouvel EF4, vous pouvez également utiliser les classes POCO, ce qui supprime la charge supplémentaire que représente le mappage des entités entre les couches. Dans notre application, nous avons utilisé EF4 et utilisé des entités métier dans toute l'application, à l'exception de la vue qui nécessite un modèle de vue. Cela a donné une augmentation significative des performances.

Answer 5

Pas avec entity framework, mais j'ai essayé de créer un exemple avec deux procédures stockées d'insertion exécutées séparément dans la couche d'accès aux données (en utilisant le bloc d'application d'accès aux données 3.1), enveloppé dans le contexte TransactionScope dans Service/BLL, cela n'a pas fonctionné. Une insertion a réussi, l'autre a échoué et les données ont été commitées.

Avez-vous réussi à le faire vous-même ?