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:
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.
Related Articles
- Preventing Cross Site Scripting Attacks in ASP.NET MVC 4
- Test Driven Development in Asp.Net MVC Architecture
- Introduction to ASP.NET vNext
- Overview of OWIN and Katana
Using the Repository Pattern with ASP.NET MVC and Entity Framework的更多相关文章
- [转]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-a ...
- ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第一章:创建基本的MVC Web站点
在这一章中,我们将学习如何使用基架快速搭建和运行一个简单的Microsoft ASP.NET MVC Web站点.在我们马上投入学习和编码之前,我们首先了解一些有关ASP.NET MVC和Entity ...
- ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之目录导航
ASP.NET MVC with Entity Framework and CSS是2016年出版的一本比较新的.关于ASP.NET MVC.EF以及CSS技术的图书,我将尝试着翻译本书以供日后查阅. ...
- 使用MiniProfiler给Asp.net MVC和Entity Framework号脉(附源码)
在学习python开发框架pylons/pyramid的过程中,里面有个非常棒的页面性能监控功能,这样在开发过程中,你能清楚的知道当前页面的性能以及其它参数. 这里介绍一下如何给Asp.net MVC ...
- ASP.NET MVC+EasyUI+Entity FrameWork 整合开发
本文详细讲解怎么用ASP.NET MVC+EasyUI+Entity FrameWork 来开发一个项目 对于ASP.NET MVC的Jscript库,主要引用 <script type=.mi ...
- Generic repository pattern and Unit of work with Entity framework
原文 Generic repository pattern and Unit of work with Entity framework Repository pattern is an abstra ...
- ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第六章:管理产品图片——多对多关系(上篇)
在这章中,我们将学习如何创建一个管理图片的新实体,如何使用HTML表单上传图片文件,并使用多对多关系将它们和产品关联起来,如何将图片存储在文件系统中.在这章中,我们还会学习更加复杂的异常处理,如何向模 ...
- ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第二章:利用模型类创建视图、控制器和数据库
在这一章中,我们将直接进入项目,并且为产品和分类添加一些基本的模型类.我们将在Entity Framework的代码优先模式下,利用这些模型类创建一个数据库.我们还将学习如何在代码中创建数据库上下文类 ...
- ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第四章:更高级的数据管理
在这一章我们将学习如何正确地删除分类信息,如何向数据库填充种子数据,如何使用Code First Migrations基于代码更改来更新数据库,然后学习如何执行带有自定义错误消息的验证. 注意:如果你 ...
随机推荐
- android 中文转拼音
/** * 将汉字转换为拼音 * @author Champion.Wong * */ public class Trans2PinYin { private static int[] pyvalue ...
- 使用 Visual Studio Team Test 进行单元测试和java中的测试
C#中test测试地 方法一. 1.从NUnit官网(http://www.nunit.org/index.php)下载最新版本NUnit,当前版本为NUnit2.5.8. 2.安装后,在VS2008 ...
- Lambda(2)
Lambda表达式是匿名方法的超集,处理匿名方法有的功能外,还有其他的功能: 1.能够推测出参数的类型,无需显示声明 2.支持语句块和表达式作为方法体 Lambda表达式的书写方式: Lambda表达 ...
- PowerPoint Office Mix 插件
一个内嵌在PowerPoint里的一个教学工具,可以以PPT为核心录制视频. 点下面链接了解并安装 https://mix.office.com/ 首先这货是免费,当然是基于PowerPoint的基础 ...
- 在Windows 上安装SQL Server的一些注意事项
基本来说安装SQL Server 单节点数据库并不是很困难的事情,大多可以通过Next来安装完成.其中要注意以下几点 安装.net3.5 可以参考本Blog的一些安装须知. Windows Serve ...
- virtualbox centos安装增强工具
系统的,VBoxLinuxAdditions-amd64.run 是用于64位系统的.执行以下命令来安装sh ./VBoxLinuxAdditions-x86.run 5.安装成功后重启系统.
- 阿里云mysql数据库恢复总结,mysql binlog日志解析
由于意外..阿里云mysql中有一张表被全部删除了,深吸三口气候,开始解决. 首先用凌晨的自动备份的,进行全量恢复,然后找binlog日志(见下文),查找从全量备份到数据删除之间的记录 这导致了一个问 ...
- iOS开发网络篇—大文件的多线程断点下载(转)
http://www.cnblogs.com/wendingding/p/3947550.html iOS开发网络篇—多线程断点下载 说明:本文介绍多线程断点下载.项目中使用了苹果自带的类,实现了 ...
- Scene (场景视图) 详解
控制二维切换的按钮 点击2D按钮可以激活2D模式.这个按钮会将场景相机在透视视图和正交投影视图之间进行切换.当观察透视视图时,远离相机的物体看起来更小:然而,当正交投影视图的时候,物体的大小并不受相机 ...
- cocos2.2.3中创建精灵对象的三大类方法
1.众生相,皆精灵 2.精灵的类继承关系 class CCSprite : public CCNode, public CCNodeRGBA, public CCTextureProtocol 3.创 ...