Question Dans une couche distincte d'accès aux données et de logique métier, puis-je utiliser les classes d'infrastructure Entity dans la couche de gestion?


Dans une couche distincte d'accès aux données et de logique métier, puis-je utiliser les classes d'infrastructure Entity dans la couche de gestion?

EDIT: Je ne pense pas que je devrais remplacer la couche d'accès aux données de ma logique métier à l'avenir (c'est-à-dire que ce sera SQL Server), mais je le ferai pour la couche d'interface utilisateur. Par conséquent, la question est plutôt de savoir s'il y a des problèmes majeurs avec l'utilisation des classes EF pour moi dans la couche métier? On dirait qu'il y aurait moins de code de plomberie.


13
2018-05-16 00:29


origine


Réponses:


En règle générale, l’approche fondée sur les «meilleures pratiques» serait la suivante:

  • dans votre couche de données, vous avez des entités EF chargées et stockées dans la base de données

  • Dans votre couche Business, vous avez vos propres objets de domaine (uniquement des classes C #) qui représentent les données sur lesquelles votre application doit travailler. Celles-ci peuvent être plus ou moins identiques à une entité de couche de données, ou elles peuvent contenir plusieurs entités "atomiques" pour constituer un objet métier, ou elles peuvent être très différentes. Pour réduire le besoin d’un grand nombre d’affectations main gauche / droite (pour déplacer des valeurs de propriété entre les entités de couche de données et les objets de couche de gestion), vous devez extraire des outils tels que AutoMapper Il est donc très facile de configurer des "mappages" entre des types d’objets similaires et d’attribuer facilement ces types

  • votre couche d'interface utilisateur visualisera et représentera les objets de la couche Business à l'utilisateur pour information et / ou manipulation.

L'avantage est que votre modèle de domaine de la couche de gestion représente les objets métier réels avec lesquels vous travaillez et devient plus ou moins indépendant de la manière dont ceux-ci sont réellement stockés dans la couche de données. Cela évite également de "coller" votre couche d'interface utilisateur à une technologie d'accès aux données particulière.

Bien sûr, c'est la meilleure pratique recommandée pour une application à l'échelle de l'entreprise, où vous pourriez avoir besoin de permuter la couche d'accès aux données, etc. Pour une application plus simple, vous pouvez ignorer ces pratiques, connaissance ce que vous faites, et que vous vous "verrouillez" dans EF si vous utilisez les entités EF tout au long de la couche de gestion dans l'interface utilisateur. Si cela vous convient et à votre scénario d'application, il n'y a aucune raison particulière de ne pas le faire. Les entités EF sont des classes d'objets .NET parfaitement valides - elles dérivent simplement d'une classe de base commune (EntityObject au lieu de object) et ils ont une certaine quantité de "bagages" qui arrive. Mais rien ne vous empêche d'utiliser ces entités EF tout au long de votre application.


15
2018-05-16 07:50



Comme pour toutes les questions de cette nature, la réponse est que cela dépend. Si vous souhaitez une séparation claire de votre logique d'accès aux données et de votre couche métier, je dirais non. Si c'est ce que vous visez, j'utiliserais un modèle de référentiel et IoC pour créer la couche d'accès aux données, puis vous pouvez échanger une DAL stub à des fins de tests unitaires, puis accéder à la base de données lorsque vous passez aux tests fonctionnels.


1
2018-05-16 05:49



Si vous devez être en mesure de modifier la façon dont vous accédez à la base de données sans avoir à réécrire sur beaucoup de code, il est préférable de garder EF hors de la couche de gestion. Vous pouvez utiliser l'unité de travail et les modèles de référentiel pour y parvenir. accéder à toutes les fonctionnalités du niveau de données via des interfaces. Si vous supprimez EF, les interfaces restent les mêmes, vous modifiez simplement les classes d'implémentation.

Cependant, il existe des arguments pour ne pas utiliser UoW ​​et le référentiel, le principal étant que DbContext vous fournit déjà plusieurs de ces fonctionnalités.

J'ai démarré un projet avec un UoI et un référentiel au niveau de la couche de données et aucune référence EF au niveau de la couche de gestion. Au fur et à mesure que je progressais, je sentais que je travaillais juste pour moi et les laissais tomber. Au lieu de cela, j'utilise l'accès au contexte à partir du niveau métier, effectue toute conversion dont j'ai besoin de la part de DTO vers le niveau métier POCO.

Dans mon scénario, je suis confiant de rester avec EF. Si vous ne l’êtes pas, considérez quelle approche vous convient.


0
2017-10-21 21:45