Repository vs modèle de service dans DAL: EF et Dapper

asp.net-mvc dapper design-patterns entity-framework

Question

Je travaille sur un projet et je dois concevoir le DAL. J'utiliserai Entity Framework pour la plupart du projet et Dapper pour certaines zones sensibles aux performances.

Je pensais utiliser le modèle Repository mais EF implémente déjà ce pattern dans un certain sens. Mais ce n'est pas le cas avec Dapper. Puis-je me demander si je peux mélanger les modèles de référentiel et de service dans ma DAL? Ou serait-ce traverser dans la couche Logic Business?

Un exemple de structure que je pensais construire:

MyProjectName.Main
    Views/
    Controllers/
    Infrastructure/
    ...
MyProjectName.DAL
    DataService.EF/
        fileName.cs
        ...
    DataService.Dapper/
        fileName.cs
        ...

Réponse acceptée

EF ou tout autre ORM n'implémente pas le référentiel. Le référentiel est destiné à découpler le domaine de la persistance. Le domaine fonctionne avec des objets de domaine, EF / Nhibernate / Dapper etc. fonctionne avec des entités de persistance, ce qui représente une vue POO de la base de données relationnelle .

Regarde la différence? L'un nécessite des objets métier, l'autre des structures de données . Ils sont similaires mais ils ne sont pas les mêmes. Concept, comportement et cas d'utilisation des modèles de domaine, Persistence se soucie de stocker les données afin de les récupérer rapidement. Des responsabilités différentes Le référentiel joue le rôle de médiateur entre eux, "convertissant" les objets de domaine en structures de persistance et vice versa.

Toujours, l'ORM est un détail d'implémentation du référentiel. Pour les applications CRUD, où vous n'avez pas vraiment de domaine, vous traitez directement avec la base de données, à savoir le (micro) ORM. Dans ce cas, le Repo n'a de sens que comme une façade pour donner un sens commercial à l'accès aux données ( GetOrders est beaucoup plus facile à comprendre qu'un ensemble de Linq ou 5 lignes SQL reliant 3 tables).

L'interface du référentiel est définie là où elle est nécessaire, mais elle est implémentée dans Persistence (DAL). De même avec les services, ils peuvent être définis (en tant qu'interface) dans le domaine alors que leur implémentation peut être dans DAL. Bien que l'implémentation du référentiel fasse presque toujours partie de DAL, seuls certains services résident dans DAL, pour la simple raison qu'il est plus facile pour eux de faire leur travail. Les autres services peuvent directement utiliser des référentiels (injectés généralement via un constructeur) et ne pas toucher à la DAL.

Quel que soit le modèle que vous utilisez, essayez de comprendre leur objectif réel et pensez toujours au découplage.


Réponse populaire

Découvrez une implémentation hybride EF + Dapper que Bradley Braithwaite a créée.

GitHub Repo: https://github.com/bbraithwaite/HybridOrm

Article de blog d'accompagnement: ORM: Ne réinventez pas la roue

En termes de structuration des couches de projet pour éviter le "saignement", voici comment il l'a fait.

Disposition du projet

À partir de l'article de blog: Création d'un référentiel de données à l'aide de Dapper



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi