Using Repository Pattern with Entity Framework

January 20, 2010

Using Repository Pattern with Entity Framework

One of the tools Using Repository Pattern with Entity Framework
for reaching for
persistence
ignorance
is to
build a facade between
the data access layer and
your business logic. Such facade will prevent the knowledge of
how the data access is working and with which technology. That
abstraction can be achieved by using the Repository Pattern.
In the post I’ll show how you can use the Repository Pattern in order
to make an abstraction layer on top of Entity Framework.

The Repository Interface

When we want to use the Repository Pattern we
start with an interface which will be our data access facade.
I’ll be using the following interface in my example:

public interface IRepository<T>
{        
    T GetById(int id);
    T[] GetAll();        
    IQueryable<T> Query(Expression<Func<T, bool>> filter);                                
}

This interface only include some of the functionality which I’ll

put in a repository. You may notice that I removed any CUD

(Create/Update/Delete) operations. In a follow up post I’ll show

how to implement these operations by using the Unit of Work

pattern.

A Repository Implementation

The following is a naive implementation for a department repository:

public class DepartmentRepository : IRepository<Department>, IDisposable
{
    #region Members
 
    private SchoolEntities _context;        
 
    #endregion
 
    #region Ctor
 
    public DepartmentRepository() 
    {            
        _context = new SchoolEntities();
    }
 
    #endregion
 
    #region IRepository<Department> Members
 
    public Department GetById(int id)
    {
        return _context.Departments.
            Where(d => d.DepartmentID == id).
            FirstOrDefault();
    }
 
    public Department[] GetAll()
    {
        return _context.Departments.ToArray();
    }
 
    public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)
    {
        return _context.Departments.Where(filter);
    }
 
    #endregion
 
    #region IDisposable Members
 
    public void Dispose()
    {
        if (_context != null) 
        { 
            _context.Dispose(); 
        } 
        GC.SuppressFinalize(this);
    }
 
    #endregion
}

This is a naive implementation since I hold a context inside my

department repository. A better solution will be to create a

context helper that will be used in order to create contexts when

they are needed. After we have the implementation we can start

using it.

The following code demonstrate how we can use the department

repository:

IRepository<Department> repository = new DepartmentRepository();
foreach (var department in repository.GetAll())
{
    Console.WriteLine(department.Name);
}
 
foreach (var department in repository.Query(d => d.Budget > 150000))
{
    Console.WriteLine("department with above 150000 budget: {0}",
        department.Name);
}            
Console.ReadLine();

Why to use the Repository Pattern?

There are a lot of reasons for using the Repository Pattern.

For example:

  • Testability. Using the pattern we can create stubs that

    can replace the real data access objects. This can

    help us to test our business logic without concerning what the

    data access is doing.

  • Abstraction. Using the pattern we create an abstraction above

    our data access functionality. This abstraction can help us when we 
    want to change the implementation of the data access without

    affecting our business logic code. For example, I had to change

    implementation of data access with a call to a web service. Using

    the pattern I only needed to change the object that I used and that is

    it.

  • Dependency Injection. Using the pattern we can use DI containers to

    inject the relevant object that we want to use in the code.

Summary

Lets sum up, the Repository Pattern is a very useful pattern to use

when we build data access layers. Like all other patterns sometimes

it can be an overkill in abstraction (in particular in small and simple applications).

In the post I showed one way to create a repository on top of Entity Framework.

I could have used any other data access frameworks as well and this is the beauty

of the pattern. In a follow up post I’ll explain what is the Unit of Work pattern and

will continue building the repository I used in this post so stay tuned.

DotNetKicks Image
Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

5 comments

  1. SMiGLJanuary 21, 2010 ב 17:52

    Grat tutorial. Thanks

    Reply
  2. LesyaJanuary 21, 2010 ב 19:14

    Thanks. It was easy to understand this material. I am waiting for new information about this theme.

    Reply
  3. MasoudJanuary 22, 2010 ב 13:47

    Great tutorial,I really love EF(specially Ef 4.0) but in most resource you can finde HN that is harder to work.

    thanks for sharing 😉

    Reply
  4. SergioJanuary 27, 2010 ב 1:37

    Good idea, but is still have a question. How is the facade going to be unit-tested since it’s still coupled with the entities?

    Reply
  5. Gil FinkJanuary 27, 2010 ב 8:30

    @Sergio,
    You can use POCO entities instead of EF generated entities and therefore not be coupled on the EF entities. Because it is a facade what is going under the hood is your own implementation. As I wrote, the implementation I’ve provided is very simple and it is only showing one simple way of how you can use a Repository.

    Reply