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

本文转自：http://www.codeguru.com/csharp/.net/net_asp/mvc/using-the-repository-pattern-with-asp.net-mvc-and-entity-framework.htm

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:

IBM Worklight Compared to "Do-It-Yourself" Mobile Platforms

Download Now

100%

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:

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:

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.