The Repo Man: Why You Should Use Repositories on Top of Entity Framework

Wednesday, February 20, 2013 @ 01:27

By: Corey Adler, Staff Developer

Microsoft’s Entity Framework is a wonderful tool to use with any .NET program. It abstracts a lot of the dirty work that would normally go into grabbing records from a database and brings the data back as actual objects that you would use in your code. An inherent part of Entity Framework’s design is the fact that it uses 2 well known design patterns: Repository and Unit of Work. It is the first one that I want to spend some time discussing.

According to Martin Fowler (http://martinfowler.com/eaaCatalog/repository.html), the Repository pattern “mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction.” In the case of Entity Framework, that means that your DbContext class acts as a middleman between your client-side code (i.e. where you need the data to go, like your UI) and the database itself. You query the DbContext, it converts the query to SQL, sends it to the database, gets back the records, and then sends it to whatever code called for it.

So, since Entity Framework does this for you out of the box, why do some people construct additional repositories to go on top of the DbContext?

Figure 1: An example Repository interface

Figure 2: Some of the interface methods from Fig. 1 as implemented

There are multiple reasons that would make applying this pattern on top of Entity Framework a good idea. Here are just a couple of reasons that should stick out:

1. Unit Testing: Trying to unit test the plain DbContext can become a logistical nightmare. In order to do so, without creating a separate database in the first place, one would have to extract many of the DbContext methods and properties—many of which are1)      part of the Framework itself, and not customized—and place them into an interface to be extended by a TestDbContext class that would have to be created. Instead, in order to test the grabbing of records you can simply have a TestRepository class that will implement the interface from Fig. 1, and base it off of an in-memory collection. No muss, no fuss, and no worrying about creating a separate database.

2. Extensibility: Recently I’ve come across a number of questions on Stack Overflow asking about doing soft deletes with Entity Framework. A soft delete is one in which the record is not actually deleted from the database but is marked as “Deleted”; this makes it very easy then to “Undelete” the item to bring it back in case of accidental deletion. Trying to do this on the DbContext would require that every query to a DbSet also include a filter for anything softly deleted. Over the course of a whole application, this can get very tedious and time consuming. Instead, with a repository class, you can easily place this line in the repository and not have to worry about it, like in Fig. 3.

Figure 3: Implementing a soft delete (some interface methods removed for clarity). Note the change in the DbSet getter above.

There are more reasons to place a repository on top of Entity Framework, but I’ll leave it at these first two for now. Until then, I wish you good coding.