What Is Repository Pattern C# ?


A Repository in C# mediates between the domain and data mapping layers (like Entity Framework). It allows you to pull a record or number of records out of datasets, and then have those records to work on acting like an in-memory domain object collection, and you can also update or delete records within those data set, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes.

Repository pattern C# is a way to implement data access by encapsulating the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.

Repository pattern C# also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.

Repository pattern C# is mostly used where we need to modify the data before passing to the next stage.

here’s an awesome graph that illustrates the idea:

Repository Pattern Structure Diagram

Why Repository Pattern C# ?

  • Increase testability: Repository systems are good for testing. One reason being that you can use Dependency Injection. Basically, you create an interface for your repository, and you reference the interface for it when you are making the object. Then you can later make a fake object (using moq for instance) which implements that interface. Using something like StructureMap you can then bind the proper type to that interface. Boom you’ve just taken a dependence out of the equation and replaced it with something testable.

  • Easily swapped out with various data stores without changing the API: For example, in one instance, you may need to retrieve data from the database, in other cases you may need to retrieve something from a third-party API, or perhaps there’s some other place from which you need to retrieve data. Regardless, the idea behind the repository pattern is that whatever sits behind it doesn’t matter so long as the API it provides works for the layer of the application calling into it.

Entity Framework Repository Pattern C#

Entity Framework (EF) itself implements Unit of work pattern and somewhat loosely implements Repository pattern. With EF you can retrieve a set of records from the database in POCO models. Also, EF keeps track of changes for you within these models and save these changes on single SaveChanges method call.

Let’s see how to create a repository using EF, let say you have customer entity in your application, then this is how your customer repository interface will look like:

public interface ICustomerRepository 
2 {        
3     IEnumerable GetCustomers();        
4     Customer GetCustomerByID(int customerId);        
5     void InsertCustomer(Customer customer);        
6     void DeleteCustomer(int customerId);        
7     void UpdateCustomer(Customer customer);        
8     void Save();    
9 }
And the implementation of the above interface with EF looks like this: 1 public class CustomerRepository:ICustomerRepository    
 2 {        
 3     private ApplicationContext context;        
 4  
 5     public CustomerRepository(ApplicationContext context)        
 6     {            
 7         this.context = context;        
 8     }        
 9     
10     public IEnumerable<Customer> GetCustomers()        
11     {            
12         return context.Customers.ToList();        
13     }        
14     public Customer GetCustomerByID(int customerId)        
15     {
16         return context.Customers.Find(customerId);
17     }
18     
19     public void InsertCustomer(Customer customer)
20     {            
21         context.Customers.Add(customer);      
22     }        
23     
24     public void DeleteCustomer(int customerId)        
25     {            
26         Customer customer = context.Customers.Find(customerId);                    
27         context.Customers.Remove(customer);        
28     }        
29     
30     public void UpdateCustomer(Customer customer)        
31     {            
32         context.Entry(customer).State = EntityState.Modified;        
33     }        
34     
35     public void Save()        
36     {            
37         context.SaveChanges();        
38     }
39     
40 }

And the implementation of the above interface with EF looks like this:

 1 using System;
 2 using System.Collections.Generic;
 3 using System.Data.Entity;
 4 using System.Linq;
 5 using System.Linq.Expressions;
 6 using System.Text;
 7 using System.Threading.Tasks;
 8 
 9 class BaseRepository<TEntity> : IRepository <TEntity> where TEntity : class
10 {
11     internal ApplicationContext context;
12     internal DbSet<TEntity> dbSet;
13 
14     public BaseRepository(ApplicationContext context)
15     {
16         this.context = context;
17         this.dbSet = context.Set<TEntity>();
18     }
19 
20     public virtual IEnumerable<TEntity> GetWithRawSql(string query, 
21         params object[] parameters)
22     {
23         return dbSet.SqlQuery(query, parameters).ToList();
24     }
25 
26     public virtual IEnumerable<TEntity> Get(
27         Expression<Func<TEntity, bool>> filter = null,
28         Func<IQueryable<TEntity>, IOrderedQueryable<TEntity>> orderBy = null,
29         string includeProperties = "")
30     {
31         IQueryable<TEntity> query = dbSet;
32 
33         if (filter != null)
34         {
35             query = query.Where(filter);
36         }
37 
38         if (includeProperties != null)
39         {
40             foreach (var includeProperty in includeProperties.Split
41             (new char[] { ',' }, StringSplitOptions.RemoveEmptyEntries))
42             {
43                 query = query.Include(includeProperty);
44             }
45         }
46             
47 
48         if (orderBy != null)
49         {
50             return orderBy(query).ToList();
51         }
52         else
53         {
54             return query.ToList();
55         }
56     }
57 
58     public virtual TEntity GetByID(object id)
59     {
60         return dbSet.Find(id);
61     }
62 
63     public virtual void Insert(TEntity entity)
64     {
65         dbSet.Add(entity);
66     }
67 
68     public virtual void Delete(object id)
69     {
70         TEntity entityToDelete = dbSet.Find(id);
71         Delete(entityToDelete);
72     }
73 
74     public virtual void Delete(TEntity entityToDelete)
75     {
76         if (context.Entry(entityToDelete).State == EntityState.Detached)
77         {
78             dbSet.Attach(entityToDelete);
79         }
80         dbSet.Remove(entityToDelete);
81     }
82 
83     public virtual void Update(TEntity entityToUpdate)
84     {
85         dbSet.Attach(entityToUpdate);
86         context.Entry(entityToUpdate).State = EntityState.Modified;
87     }
88 }

The above generic repository defines core operations. You can extend this class and interface base on business requirement and can inherit in your custom repository.

Unit Of Work Pattern C#

Use of separate repository for a single transaction could result in partial updates. For example, suppose you have to update two different entity types as part of the same transaction. If each uses a separate database context instance, one might succeed and the other might fail, and one way to ensure that all repositories use the same database context (and thus coordinate all updates) is to use a unit of work class.

Unit of work pattern is easy to implement with the use of a generic repository. Let’s see an example,

1 using System;
2 using System.Collections.Generic;
3 
4 public interface IUnitOfWork
5 {
6     IRepository<Customer> Customers { get; }
7     IRepository<Order> Orders { get; }
8     void Commit();
9 }

Below is the code of how the implementation of above IUnitOfWork will look like,

 1 using System;
 2 using System.Collections;
 3 using System.Collections.Generic;
 4 using System.Data.Entity;
 5 using System.Linq;
 6 using System.Text;
 7 using System.Threading.Tasks;
 8 
 9 public class UnitOfWork : IUnitOfWork
10 {
11 
12     private ApplicationContext _dbContext;
13     private BaseRepository<Customer> _customers;
14     private BaseRepository<Order> _orders;
15 
16     public UnitOfWork(ApplicationContext dbContext)
17     {
18         _dbContext = dbContext;
19     }
20 
21     public IRepository<Customer> Customers
22     {
23         get
24         {
25             return _customers ?? 
26                 (_customers=new BaseRepository<Customer>(_dbContext));
27         }
28     }
29 
30     public IRepository<Order> Orders
31     {
32         get
33         {
34             return _orders ?? 
35                 (_orders=new BaseRepository<Order>(_dbContext));
36         }
37     }
38 
39     public void Commit()
40     {
41         _dbContext.SaveChanges();
42     }
43 }


Unit of Work is the concept related to the effective implementation of the repository pattern, whether its non-generic repository pattern or generic repository pattern.

Unit of Work is referred to as a single transaction that involves multiple operations of insert/update/delete and so on. You can learn more about Unit of Work from this awesome post.

Repository Pattern C# MVC

Let’s see now how our controller code will look like after using repository pattern along with unit of work:

 1 public class CustomerController : Controller
 2 {
 3   private UnitOfWork unitOfWork = new UnitOfWork();
 4 
 5   // GET: /Customer/
 6   public ViewResult Index()
 7   {
 8      var Customers = unitOfWork.CustomerRepository.Get();
 9      return View(Customers.ToList());
10   }
11 
12   // GET: /Customer/Details/5
13   public ViewResult Details(int id)
14   {
15      Customer Customer = unitOfWork.CustomerRepository.GetByID(id);
16      return View(Customer);
17   }
18 
19   // GET: /Customer/Create
20   public ActionResult Create()
21   {
22      return View();
23   }
24 
25   [HttpPost]
26   [ValidateAntiForgeryToken]
27   public ActionResult Create(Customer Customer)
28   {
29      try
30      {
31         if (ModelState.IsValid)
32         {
33            unitOfWork.CustomerRepository.Insert(Customer);
34            unitOfWork.Save();
35            return RedirectToAction("Index");
36         }
37      }
38      catch (DataException)
39      {
40         ModelState.AddModelError("", "Unable to save changes.");
41      }
42      return View(Customer);
43   }
44 
45   public ActionResult Edit(int id)
46   {
47      Customer Customer = unitOfWork.CustomerRepository.GetByID(id);     
48      return View(Customer);
49   }
50 
51   [HttpPost]
52   [ValidateAntiForgeryToken]
53   public ActionResult Edit(       
54      Customer Customer)
55   {
56      try
57      {
58         if (ModelState.IsValid)
59         {
60            unitOfWork.CustomerRepository.Update(Customer);
61            unitOfWork.Save();
62            return RedirectToAction("Index");
63         }
64      }
65      catch (DataException)
66      {
67         ModelState.AddModelError("", "Unable to save changes.");
68      }
69      return View(Customer);
70   }
71 
72   // GET: /Customer/Delete/5
73   public ActionResult Delete(int id)
74   {
75      Customer Customer = unitOfWork.CustomerRepository.GetByID(id);
76      return View(Customer);
77   }
78 
79   // POST: /Customer/Delete/5
80   [HttpPost, ActionName("Delete")]
81   [ValidateAntiForgeryToken]
82   public ActionResult DeleteConfirmed(int id)
83   {
84      Customer Customer = unitOfWork.CustomerRepository.GetByID(id);
85      unitOfWork.CustomerRepository.Delete(id);
86      unitOfWork.Save();
87      return RedirectToAction("Index");
88   }
89 
90   protected override void Dispose(bool disposing)
91   {
92      unitOfWork.Dispose();
93      base.Dispose(disposing);
94   }
95 }

In the above code we directly initialized unitOfWork variable. Like this,

1 private UnitOfWork unitOfWork = new UnitOfWork();

However to truly use the power of repository pattern and make the above controller testable we need to use IUnitOfWork instead of UnitOfWork for our unitOfWork variable data type, and also we have to initialize it using Dependency Injection (DI) technique.

Assuming you’re starting with a new ASP.NET MVC 5 application, the easiest way to get StructureMap is using Nuget package StructureMap.MVC5.

After installing StructureMap, from solution explorer we can notice that Dependency Resolution folder has been added, also StructuremapMVC.cs file in App_Start folder.

The important file which is needed is the DefaultRegistry.cs. In Default Registry class, we are going configure StructureMap container. Let’s see how:

 1 public class DefaultRegistry : Registry 
 2 {
 3     #region Constructors and Destructors
 4 
 5     public DefaultRegistry() 
 6     {
 7         Scan(
 8             scan => {
 9                 scan.TheCallingAssembly();
10                 scan.WithDefaultConventions();
11 
12                 //This line of code is just directions telling StructureMap 
13                 //where to look for DAL models.  
14                 //Typically, my DAL code lives in different class library
15                 scan.AssemblyContainingType<ApplicationDbContext>();
16 
17                 //To connect implementations to our open generic type of IRepository, 
18                 //we use the ConnectImplementationsToTypesClosing method.  
19                 scan.ConnectImplementationsToTypesClosing(typeof(IRepository<>));
20             });
21         //For<IExample>().Use<Example>();
22 
23         //Here we resolve object instances of our DbContext and IRepository
24         For<DbContext>().Use(ctx => new ApplicationDbContext());
25         For(typeof(IRepository<>)).Use(typeof(BaseRepository<>));
26     }
27 
28     #endregion
29 }

After configuring DefaultRegistry replace your CustomerController unitOfWork initialization code with the below code:

 1 public class CustomerController : Controller
 2 {
 3   private readonly IUnitOfWork unitOfWork;
 4 
 5   public CustomerController (IUnitOfWork unitOfWork)
 6   {
 7       this.unitOfWork = unitOfWork;
 8   }
 9 
10 }