Repository vs Service pattern in DAL: EF and Dapper
asp.net-mvc dapper design-patterns entity-framework
Question
I'm working on project and I need to design the DAL. I will be using Entity Framework for most of the project and Dapper for some performance-sensitive areas.
I was thinking about using the Repository pattern but then EF already implements this pattern in some sense. But that's not the case with Dapper. Then I am wondering is it valid to mix Repository and Service patterns in my DAL? Or would this be crossing into the Business Logic Layer?
A sample structure I was thinking to buid:
MyProjectName.Main
Views/
Controllers/
Infrastructure/
...
MyProjectName.DAL
DataService.EF/
fileName.cs
...
DataService.Dapper/
fileName.cs
...
Accepted Answer
EF or any other ORM doesn't implement the Repository. The Repository is meant to decouple the Domain from the Persistence. Domain works with domain objects, EF/Nhibernate/Dapper etc work with persistence entities which represents an OOP view of the relational database.
See the difference? One needs business objects, the other deals with data structures. They are similar but they are not the same. Domain models concept, behavior and use cases, Persistence cares about storing data so that is fast retrieved. Different responsibilities. The Repository acts as mediator between them, "converting" Domain objects in persistence structures and vice verse.
Always, the ORM is a implementation detail of the Repository. For CRUD apps, where you don't really have a Domain you're dealing directly with the db i.e the (micro)ORM. In that case the Repo makes sense only as a facade to give some business meaning to data access ( GetOrders is much easier to understand that a whole Linq or 5 lines SQL joining 3 tables).
The Repository interface is defined where it's needed, but it's implemented in Persistence (DAL). Same with Services,they can be defined (as an interface) in the Domain while their implementation can be in DAL. While Repository implementation almost always is part of DAL, only some Services reside in DAL, for the simple reason that it's easier for them to do their job that way. Other Services can directly use repositories (injected usually via constructor) and don't touch the DAL.
Whatever pattern you use, try to understand their actually purpose and always think about decoupling.
Popular Answer
Check out an EF + Dapper Hybrid Implementation that Bradley Braithwaite has created.
GitHub Repo: https://github.com/bbraithwaite/HybridOrm
Accompanying Blog Post: ORMs: Don't Reinvent the Wheel
In terms of structuring the Project Layers to avoid "bleeding", here's how he did it.
From Blog Post: Creating Data Repository Using Dapper
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
