Using the Repository Pattern with ASP.NET MVC and Entity Framework

Introduction

Data driven web applications need to have a neat strategy for data access. One of the important aspects of this strategy is the separation between the physical database, queries and other data access logic from the rest of the application. Repository pattern is a popular way to achieve such an isolation. This article discusses the basics of Repository pattern in the context of Entity Framework and ASP.NET MVC. It also illustrates how a repository can be built around your entities.

Overview of the Repository Pattern?

Most of the business applications need to access data residing in one or the other data store. The simplest approach is to write all the data access code in the main application itself. Consider, for example, that you have an ASP.NET MVC controller named CustomerController. The Customer controller class has several action methods that ultimately perform typical CRUD (Create, Read, Update and Delete) operations on the underlying database. Let's further assume that you are using Entity Framework for database access. In this case your application would do something like this:

Custom Controller

As you can see, various actions of the Customer controller (not all are shown in the figure) directly instantiate the EF data context and fire queries to retrieve the data. They also INSERT, UPDATE and DELETE data using the data context and DbSet. The EF in turn talks with the underlying SQL Server database. Although the above application works as expected it suffers from the drawback that the database access code (creating data context, writing queries, manipulating data, persisting changes etc.) is embedded directly inside the action methods. This design can cause code duplication and the controller is susceptible to change even for a minute change in the data access logic. For example, if an application is modifying a customer from two controllers, each controller will repeat the same code. And any future modifications also need to be done at two places.

To tackle this shortcoming Repository pattern can be introduced. The following line summarizes the purpose of the Repository pattern:

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

(Read more about repository pattern here.)

Thus a repository acts like a middleman between the rest of the application and the data access logic. A repository isolates all the data access code from rest of the application. In doing so you are benefited by having a simple point of change in case modifications are necessary. Additionally, testing your controllers becomes easy because the testing framework need not run against the actual database access code. An in-memory or local pseudo-database would do the trick. With a repository introduced, the above figure can be changed to:

Customer Repository

With the changed design, the Customer controller won't talk with EF data context directly. Additionally, there won't be queries or any other database operations in the action methods. All these operations are wrapped by the Customer repository. The Customer repository in turn uses EF data context to get the job done. Notice that the Customer repository has methods such as SelectAll(), SelectByID(), Insert(), Update() and Delete(). The Customer controller uses these methods to get its job done. If you see the Customer repository - it is offering an in-memory collection like interface to its consumer (for example, many collection classes expose Add() and Remove() methods and allow you to query them).

Creating Model using Entity Framework

Now that you understand the basics of Repository pattern, let's create a sample application that illustrates what we've discussed so far. Create a new ASP.NET MVC web application based on the empty template. Right click on the Models folder and add an ADO.NET Entity Data Model for the Customers table of the Northwind database. The following figure shows how the Customer entity looks:

Customer Properties

Various views of the Customer controller need the Customer entity for their display so it needs to be passed between repository, controller and the views. 

Creating Customer Repository

A repository typically does at least five operations - Selecting all records from a table, selecting a single record based on its primary key, Insert, Update and Delete. This list is, however, not rigid. You may have more or fewer methods in the repository. For the sake of our example let's decide that these five operations are needed from the Customer repository. To enforce that all the repository classes have these five methods we will define an interface - ICustomerRepository - that has these methods and then we will implement this interface in a class. Creating an interface will also help us during testing where we may be required to define an alternate in-memory repository for the sake of simplicity. The ICustomerRepository interface looks like this:

public interface ICustomerRepository
{
  IEnumerable<Customer> SelectAll();
  Customer SelectByID(string id);
  void Insert(Customer obj);
  void Update(Customer obj);
  void Delete(string id);
  void Save();
}

The ICustomerRepository interface has five methods as listed below:

  • SelectAll() : This method is intended to return all the Customer entities as an enumerable collection (such as a generic List).
  • SelectByID() : This method accepts a string representing a customer ID (CustomerID is a character column in the database) and returns a single Customer entity matching that ID.
  • Insert(): This method accepts a Customer object and adds it to the Customers DbSet.
  • Update() : This method accepts a Customer object and marks it as a modified Customer in the DbSet.
  • Delete() : This method accepts a CustomerID and removes that Customer entity from the Customers DbSet.
  • Save() : This method saves the changes to Northwind database.

Next, add CustomerRepository class to the project and implement ICustomerRepository in it. The following code shows the completed CustomerRepository class.

public class CustomerRepository:ICustomerRepository
{
    private NorthwindEntities db = null;

    public CustomerRepository()
    {
        this.db = new NorthwindEntities();
    }

    public CustomerRepository(NorthwindEntities db)
    {
        this.db = db;
    }

    public IEnumerable<Customer> SelectAll()
    {
        return db.Customers.ToList();
    }

    public Customer SelectByID(string id)
    {
        return db.Customers.Find(id);
    }

    public void Insert(Customer obj)
    {
        db.Customers.Add(obj);
    }

    public void Update(Customer obj)
    {
        db.Entry(obj).State = EntityState.Modified;
    }

    public void Delete(string id)
    {
        Customer existing = db.Customers.Find(id);
        db.Customers.Remove(existing);
    }

    public void Save()
    {
        db.SaveChanges();
    }
}

The CustomerRepository class implements all the five methods discussed above. Notice that it has two constructor definitions - one that takes no parameters and the one that accepts the data context instance. This second version will be useful when you wish to pass the context from outside (such as during testing or while using the Unit of Work pattern). All the method implementations of CustomerRepository are quite straightforward and hence we won't go into detailed discussion of these methods.

Using Customer Repository in a Controller

Now that you have built the Customer repository, let's use it in a controller. So, add a controller class inside the Controllers folder and name it CustomerController. The following code shows how CustomerController looks:

public class CustomerController : Controller
{
    private ICustomerRepository repository = null;

    public CustomerController()
    {
        this.repository = new CustomerRepository();
    }

    public CustomerController(ICustomerRepository repository)
    {
        this.repository = repository;
    }


    public ActionResult Index()
    {
        List<Customer> model = (List<Customer>)repository.SelectAll();
        return View(model);
    }

    public ActionResult New()
    {
        return View();
    }

    public ActionResult Insert(Customer obj)
    {
        repository.Insert(obj);
        repository.Save();
        return View();
    }

    public ActionResult Edit(string id)
    {
        Customer existing = repository.SelectByID(id);
        return View(existing);
    }

    public ActionResult Update(Customer obj)
    {
        repository.Update(obj);
        repository.Save();
        return View();
    }

    public ActionResult ConfirmDelete(string id)
    {
        Customer existing = repository.SelectByID(id);
        return View(existing);
    }

    public ActionResult Delete(string id)
    {
        repository.Delete(id);
        repository.Save();
        return View();
    }

}

The Customer controller has two versions of the constructor and seven action methods. Notice that there is a private variable of type ICustomerRepository at the class level. The parameter less constructor sets this variable to an instance of CustomerRepository. The other version of the constructor accepts an implementation of ICustomerRepository from the external world and sets it to the private variable. This second version is useful during testing where you will supply a mock implementation of Customer repository from the test project.

The seven methods defined by the Customer controller are as follows:

  • Index() : Displays Index view and passes a List of Customer entities as its model.
  • New() : Displays New view.
  • Insert() : New view submits data to this method. It receives the data as a Customer instance and then inserts a customer using the repository.
  • Edit() : Displays Edit view. It accepts a CustomerID as an id route parameter and populates the Edit view with the data of the existing Customer.
  • Update() : Edit view submits data to this method. It receives the data as a Customer instance and then updates a customer using the repository.
  • ConfirmDelete() : Displays ConfirmDelete view.
  • Delete() : ConfirmDelete view submits to this action method. The action then deletes the Customer using the repository.

We won't go into the details of the four views mentioned above (Index, New, Edit and ConfirmDelete). They are quite simple and you can add them on your own for the sake of testing.

You just created and successfully used Repository pattern! As you can see from the controller code, nowhere did you use data context or EF operations. You always called some or the other method of the CustomerRepository to get the job done. Thus all your data access code is now separated into the repository.

Testing a Controller

Earlier we mentioned that repository pattern also helps during the testing phase. Let's see how by creating a simple test. Add a new Test project to the same solution and refer the MVC project into it. Inside the test project we will define another repository that works on some in-memory collection instead of the actual database. To create the repository add a class to the test project and write the following code to it:

class TestCustomerRepository:ICustomerRepository
{
    private List<Customer> data = new List<Customer>();

    public IEnumerable<Customer> SelectAll()
    {
        return data;
    }

    public Customer SelectByID(string id)
    {
        return data.Find(m => m.CustomerID == id);
    }

    public void Insert(Customer obj)
    {
        data.Add(obj);
    }

    public void Update(Customer obj)
    {
        Customer existing = data.Find(m => m.CustomerID == obj.CustomerID);
        existing = obj;
    }

    public void Delete(string id)
    {
        Customer existing = data.Find(m => m.CustomerID == id);
        data.Remove(existing);
    }

    public void Save()
    {
        //nothing here
    }
}

As you can see TestCustomerRepository class implements the same ICustomerRepository interface defined in the MVC project. It then implements all five methods against an in-memory List of Customer entities. Although not shown in the above code, you could have pre-populated the List with some mock data.

Once TestCustomerRepository is created you can instantiate it in a test method and pass it to the CustomerController like this:

[TestMethod]
public void TestMethod1()
{
    TestCustomerRepository repository = new TestCustomerRepository();
    CustomerController controller = new CustomerController(repository);
    var result = (ViewResult)controller.Index();
    List<Customer> data = (List<Customer>)result.ViewData.Model;
    Assert.IsFalse(data.Count <= 0);
}

Recollect that CustomerController has an overloaded version of the constructor that takes any implementation of ICustomerRepository from the external world. The above code creates an instance of TestCustomerRepository and passes it to the CustomerController. It then invokes the Index() action method of the controller. The model of the Index view is obtained using the ViewData.Model property. The Assert checks whether there are any items in the model collection using IsFalse() method. In this case since no data is added to the generic List of Customer, the Count will be 0 and hence the condition will evaluate to true causing the assertion to fail.

Making the Repository Generic

Although the above example works great, it has a drawback. It expects you to have a separate repository for each entity in the application. For example, CustomerRepository for Customer entity, EmployeeRepository for Employee entity and so on. This can be too much work, especially if all the repositories are doing the same kind of operations (typical CRUD as in our example). Wouldn't it be nice to create a generic repository that can be used with any entity? Let's attempt to do just that.

Add the following interface to the ASP.NET MVC project:

public interface IGenericRepository<T> where T:class
{
    IEnumerable<T> SelectAll();
    T SelectByID(object id);
    void Insert(T obj);
    void Update(T obj);
    void Delete(object id);
    void Save();
}

The IGenericRepository interface is a generic interface that defines the same set of methods as before. Notice that this time instead of Customer entity it uses T everywhere. Also notice that SelectByID() and Delete() methods now accept object parameter instead of string. This is necessary because different tables may have different types of primary keys (Customers table has a string primary key whereas Employees table has an integer primary key).

Now, add a class to the ASP.NET MVC project that implements IGenericRepository interface. This class is shown below:

public class GenericRepository<T>:IGenericRepository<T> where T : class
{
    private NorthwindEntities db = null;
    private DbSet<T> table = null;

    public GenericRepository()
    {
        this.db = new NorthwindEntities();
        table = db.Set<T>();
    }

    public GenericRepository(NorthwindEntities db)
    {
        this.db = db;
        table = db.Set<T>();
    }

    public IEnumerable<T> SelectAll()
    {
        return table.ToList();
    }

    public T SelectByID(object id)
    {
        return table.Find(id);
    }

    public void Insert(T obj)
    {
        table.Add(obj);
    }

    public void Update(T obj)
    {
        table.Attach(obj);
        db.Entry(obj).State = EntityState.Modified;
    }

    public void Delete(object id)
    {
        T existing = table.Find(id);
        table.Remove(existing);
    }

    public void Save()
    {
        db.SaveChanges();
    }
}

The GenericRepository is a generic class and implements IGenericRepository. Notice that since this class uses generic type T you can't access a DbSet as a property of data context. That's why a generic DbSet variable is declared at the top that points to an appropriate DbSet based on the type of T.

Once GenericRepository is ready you can use it in the Customer controller like this:

public class CustomerController : Controller
{
    private IGenericRepository<Customer> repository = null;

    public CustomerController()
    {
        this.repository = new GenericRepository<Customer>();
    }

    public CustomerController(IGenericRepository<Customer> repository)
    {
        this.repository = repository;
    }
    ...
    ...
}

As shown above, the IGenericRepository variable is declared with Customer as its type. The constrictor then assigns an instanced of GenericRepository() or some other implementation of IGenericRepository to this variable. 

Testing a Controller using Generic Repository

Just like you tested the CustomerController by creating a mock implementation of ICustomerRepository, you can also test it by creating a mock implementation of IGenericRepository. The following code shows one such implementation:

class TestGenericRepository<T>:IGenericRepository<T> where T:class
{
    private List<T> data = new List<T>();

    public IEnumerable<T> SelectAll()
    {
        return data;
    }

    public T SelectByID(object id)
    {
        return data.FirstOrDefault();
    }

    public void Insert(T obj)
    {
        data.Add(obj);
    }

    public void Update(T obj)
    {
        T existing = data.FirstOrDefault();
        existing = obj;
    }

    public void Delete(object id)
    {
        data.RemoveAt(0);
    }

    public void Save()
    {
        //nothing here
    }
}

The TestGenericRepository class creates an implementation of IGenericRepository that works against an in-memory List of entities. Notice that just for the sake of testing, SelectByID(), Update() and Delete() methods return the first item from the List.

Now you can write another test method that uses TestGenericRepository repository.

[TestMethod]
public void TestMethod2()
{
    TestGenericRepository<Customer> repository = new TestGenericRepository<Customer>();
    CustomerController controller = new CustomerController(repository);
    var result = (ViewResult)controller.Index();
    List<Customer> data = (List<Customer>)result.ViewData.Model;
    Assert.IsFalse(data.Count <= 0);
}

As you can see this time TestGenericRepository is instantiated for the Customer entity and passed to the CustomerController. The remaining part of the test is identical to the earlier test method you wrote.

Summary

The Repository pattern allows you to separate data access code from the rest of the system. This isolation promotes code reuse, minimizes future modifications to code and also simplifies testing of the controller classes. This article gave you an understanding of the Repository pattern in the context of ASP.NET MVC and Entity Framework. You created entity specific repositories as well as generic repositories. You also used them in a test project.



Related Articles

Comments

  • Great article

    Posted by Jonathan on 05/09/2014 06:15am

    Thanks for the great article! It makes things clear on how to use the repository pattern to abstract data logic even deeper that typical MVC. Perhaps call this R-MVC? It becomes powerful when: 1) The data to web application relationship changes. 2) You wish to use Unit Testing 3) You need to develop in an environment where you can not connect to the real data. And especially useful when used in conjunction with a product like Ninject.

    • Finally,

      Posted by JY on 07/02/2014 10:40am

      I've been taking trying to learn the best approach for using the repository pattern and you just broke it down Barney style! Thank you for taking the time to publish your knowledge and share with us other developers using MVC.

      Reply
    Reply
  • Do NOT do this with Entity Framework

    Posted by Vesselin Obreshkov on 05/01/2014 08:00am

    This is completely unnecessary when using Entity Framework. As others have mentioned EF itself essentially gives you repository pattern and unit of work. You are just adding extra code that solves nothing and if anything is likely to give you headaches down the road. Most of the points in the article are also invalid. For instance if you're updating a customer from two different controllers, whether you use repository pattern or not - you have the exact same code duplication. And good luck trying to do any sane performance optimizations down the road when you have abstracted away the database abstraction ;) I don't understand why to this day people keep insisting on Repository patterns. You are not using direct SQL and readers and adapters inside your repository. Long story short - DON'T DO THIS with EF or any other modern ORM. Just by using EF you already use repository pattern.

    • How to implement Repository pattern using SQL, Readers and adapters inside it

      Posted by Nuwan on 06/21/2014 07:22pm

      HI Vesselin, I also used to implement repository pattern as some kind of similar to the above example. Please publish here or send a mail of your way sample which is used repository pattern with SQL, Readers and adapters. Thanks, Nuwan

      Reply
    Reply
  • Unit testing anyone?

    Posted by Guillaume Davion on 05/01/2014 12:31am

    This pattern is used to allow unit testing. Unit testing needs to be done in isolation. This controller is very simple so it doesn't seem that important, but what about a controller that does some stuff in addition to simply selecting or modifying entities? (data transformation/validation etc...). If you work directly with the database, it makes it complicated to unit test your code, hence the need to put a layer to simulate the data access to do repeatable tests

    Reply
  • No need of repository and unit of work pattern

    Posted by Jalpesh Vadgama on 04/30/2014 10:30pm

    With entity framework 6.0. It already implements the Repository pattern and unit of work behind the scene. You don't need to create one extra layer of abstraction.

    Reply
  • Redundant

    Posted by Rene Pilon on 04/23/2014 11:39am

    The above is completely redundant and an extra layer for nothing. The repository pattern is not needed with EF - if you use LINQ properly. Actually - I just removed that type of exact layer (repo) from a system written by a dev house that did not fully grasp the power of EF and LINQ.

    Reply
  • Unnecessary abstraction

    Posted by Matt on 04/10/2014 02:26am

    Well written article, but all your GenericRepository actually does is give new names to methods that already existed in the DataContext. The DataContext itself is an implementation of the repository pattern.

    Reply
  • Vice President of Nothing

    Posted by Yves Reynhout on 04/10/2014 01:41am

    My heart is bleeding ... this is not what the repository pattern is about.

    • Repository

      Posted by Zia on 05/08/2014 10:37pm

      Give reference to an article that correctly explain the repository pattern

      Reply
    Reply
  • Why?

    Posted by Rene Pilon on 04/09/2014 09:45am

    Why would you want to add another unnecessary layer (repository) on top of EF? That stuff makes my eyes bleed.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Cisco and Intel have harnessed flash memory technology and truly innovative system software to blast through the boundaries of today's I/O-bound server/storage architectures. See how they are bringing real-time responsiveness to data-intensive applications—for unmatched business advantage. Sponsored by Cisco and Intel® Partnering in Innovation

  • "Security" is the number one issue holding business leaders back from the cloud. But does the reality match the perception? Keeping data close to home, on premises, makes business and IT leaders feel inherently more secure. But the truth is, cloud solutions can offer companies real, tangible security advantages. Before you assume that on-site is the only way to keep data safe, it's worth taking a comprehensive approach to evaluating risks. Doing so can lead to big benefits.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds