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.

Project Layout

From Blog Post: Creating Data Repository Using Dapper



Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Is this KB legal? Yes, learn why