Repository Encapsulation

It’s important to consider how strictly you should encapsulate your data access logic within the repository layer

Repository Layers allow us to abstract our data access away from our application.

There are two common approaches.

 

Approach #1: Fully Encapsulated – The Strict Repository

In this model you pass in simple types or DTOs as parameters to repository methods and receive enumerated lists of results in return. (ie. IEnumerable / ICollection / IList)

 

Benefit: Your data access is 100% completely abstracted away from your core application.
This model only requires the Entity Framework to be added to your Data project.

Cons: It’s more work. Every data access query requires a new repository method and a change to the interface.

 

Approach #2: The Flexible Repository

In this model you encapsulate complex queries, or queries that will be re-used inside your repository, but simple queries can be performed by the calling client because the Get() method accepts a filter operator and returns an IQueryable that provides great flexibility.

 

Benefit: It’s less work. A developer can build user interface that performs simple CRUD operations on the entity without needing to add methods to the Repository.

 

Cons: This is a ‘leaky’ abstraction where your implementation is likely to leak into your other layers. The Entity Framework is required as a reference in any project where you are performing queries that require EF specific extensions (e.g. .Include(c=>c.Children) )

 

For each application you need to weight the cons and benefits of the two options.

For a long-lived enterprise application, I recommend fully encapsulated repositories.

For simple applications that are essentially providing forms over data functionality, the flexible repository enables developers to quickly add value to the application, while still leveraging most of the benefits of implementing a repository layer.

 

TODO: Add Code Samples