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

Answer 1

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.