Using Repository Pattern in Entity Framework

Using Repository Pattern in Entity Framework

Rate This
  • Comments 8

One of the most common pattern is followed in the world of Entity Framework is “Repository Pattern”. Since this is something which is heavily used and being practiced, I am not going to talk about the core pattern. Rather, try to show how one can implement it.

Objectives

As mentioned in http://msdn.microsoft.com/en-us/library/ff649690.aspx

  • You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
  • You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
  • You want to implement and centralize a caching strategy for the data source.
  • You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
  • You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
  • You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
  • You want to apply a domain model to simplify complex business logic.

Simple approach to ADO.NET Entity Framework

Let’s have one domain class called “Employee”

public class Employee
{
    public int Id { get; set; }
    public string FullName { get; set; }
}
Now using this we will have a simple context class
public class HRContext : DbContext
{        
    public DbSet<DomainClasses.Employee> Employees { get; set; }
}
After that, define the repository interface IEmployeeRepository
public interface IEmployeeRepository : IDisposable
{
    IQueryable<Employee> All { get; }
    IQueryable<Employee> AllIncluding(params Expression<Func<Employee, object>>[] includeProperties);
    Employee Find(int id);
    void InsertOrUpdate(Employee employee);
    void Delete(int id);
    void Save();
}
Then the Repository class called EmployeeRepository
public class EmployeeRepository : IEmployeeRepository
{
    HRContext context = new HRContext();
    public IQueryable<Employee> All
    {
        get { return context.Employees; }
    }
    public IQueryable<Employee> AllIncluding(params Expression<Func<Employee, object>>[] includeProperties)
    {
        IQueryable<Employee> query = context.Employees;
        foreach (var includeProperty in includeProperties) {
            query = query.Include(includeProperty);
        }
        return query;
    }
    public Employee Find(int id)
    {
        return context.Employees.Find(id);
    }
    public void InsertOrUpdate(Employee employee)
    {
        if (employee.Id == default(int)) {
            // New entity
            context.Employees.Add(employee);
        } else {
            // Existing entity
            context.Entry(employee).State = EntityState.Modified;
        }
    }
    public void Delete(int id)
    {
        var employee = context.Employees.Find(id);
        context.Employees.Remove(employee);
    }
    public void Save()
    {
        context.SaveChanges();
    }
    public void Dispose() 
    {
        context.Dispose();
    }
}
Then you should be implementing it in your apps (any type Windows or Web), like a Console Application
namespace ConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            GetSomeEmployee();
        }
        private static void IntiateData()
        {
            using (var repo = new EmployeeRepository())
            {
                Employee em = new Employee() { FullName = "Wriju" };
                repo.InsertOrUpdate(em);
                repo.Save();
            }
        }
        private static void GetSomeEmployee()
        {
            using (var repo = new EmployeeRepository()) 
            {
                foreach (var emp in repo.All)
                {
                    Console.WriteLine("{0} - {1}", emp.Id, emp.FullName);
                }
            }            
        }
    }
}
This obviously simple approach. The recommended options are to make the Repository generic and handle the related entities. I will discuss about them later.
Namoskar!!!
Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
  • Very Helpful

  • Your abstraction layer is leaky.

    When you are returning an `IQueryable`, it means, its end is open. the consumer is able to do whatever he wants to that `expression` and changing the propose of the method completely.

  • I don't agree with your implementation of InsertOrUpdate(...) - you're making the assumption that Id is int, and further also that the consumer hasn't set the value for Id yet. There are properties in EF that will let you handle this better.

  • I find that you are letting EF leak into your repository thinking.  For instance, InsertOrUpdate.  I prefer a simpler approach to my interfaces with a single Save(entity) method.  The code you have inside InsertOrUpdate would move inside Save along with the call to _context.SaveChanges().

  • Thanks

  • Very nice example, but there is no singleton for the context object. Could you help to modify using singleton for context. In the case we create many repositories, it would create many context objects

  • Thankq very much and it is very clear.

  • You might want to read this article for Ayende's criticism of this approach towards implementing the Repoistory pattern on top of Entity Framework (or indeed any ORM): "Architecting in the pit of doom: The evils of the repository abstraction layer" ayende.com/.../architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

Page 1 of 1 (8 items)