Repository vs Service pattern in DAL: EF and Dapper

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
        ...

Answer 1

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

Answer 2

I can say that your issue is common enough and it has a common solution - CQRS (Command Query Responsibility Segregation). This pattern is widely used when people practice DDD (Domain Driven Design) in their projects and face difficulties with some performance-sensitive areas.

There is no difference what ORM you will use. It is OK to have different components that retrieve data.

You can use Repositories or/and Entity Framework and use all its features for most of the project to perform C-reate R-ead U-pdate D-elete operations.

But for some performance-sensitive areas you can use Queries. They will return DTOs filled by Dapper (R-ead operations).

Answer 3

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.