Generic Repository Pattern in MVC3 Application With Entity Framework: Part 6

Introduction

Creating a Generic Repository Pattern in MVC3 Application with Entity Framework is the last topic that we are about to cover in our journey of Learning MVC.

This article will focus on the Unit Of Work Pattern and Repository Pattern, and shows how to perform CRUD operations in an MVC application when there is the possibility of creating more than one repository class. To overcome this possibility and overhead, we make a Generic Repository class for all other repositories and implement a Unit of Work pattern to provide abstraction.

Our roadmap towards Learning MVC

Just as a reminder, our full roadmap towards learning MVC is:

Prerequisites

There are a few prerequisites before we starting with the article; they are:

We have a running sample application that we created in the fifth part of the article series.
We have the EntityFramework 4.1 package or DLL in our local system.
We understand how a MVC application is created (follow the second part of the series).

Why Generic Repository

We have already discussed what the Repository Pattern is and why we need the Repository Pattern in our last article. We created a User Repository for performing CRUD operations, but think of the scenario where we need 10 such repositories.

Are we going to create these classes? That is not good, it results in a lot of redundant code. So to overcome that we'll create a Generic Repository class that will be called by a property to create a new repository, thus we do not get many results in many classes and also avoid redundant code. Moreover we save a lot of time that could be wasted creating those classes.

Unit of Work Pattern

According to Martin Fowler, the Unit of Work Pattern "Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.".

From MSDN:

"The Unit of Work pattern isn't necessarily something that you will explicitly build yourself, but the pattern shows up in nearly every persistence tool. The ITransaction interface in NHibernate, the DataContext class in LINQ to SQL, and the ObjectContext class in the Entity Framework are all examples of a Unit of Work. For that matter, the venerable DataSet can be used as a Unit of Work.

Other times, you may want to write your own application-specific Unit of Work interface or class that wraps the inner Unit of Work from your persistence tool. You may do this for a number of reasons. You might want to add application-specific logging, tracing, or error handling to transaction management. Perhaps you want to encapsulate the specifics of your persistence tooling from the rest of the application. You might want this extra encapsulation to make it easier to swap out persistence technologies later. Or you might want to promote testability in your system. Many of the built-in Unit of Work implementations from common persistence tools are difficult to deal with in automated unit testing scenarios.

The Unit of Work class can have methods to mark entities as modified, newly created, or deleted. The Unit of Work will also have methods to commit or roll back all of the changes as well.

The responsibilities of the Unit of Work are to:

Manage transactions.

Order the database inserts, deletes, and updates.

Prevent duplicate updates. Inside a single usage of a Unit of Work object, various parts of the code may mark the same Invoice object as changed, but the Unit of Work class will only issue a single UPDATE command to the database.

The value of using a Unit of Work pattern is to free the rest of our code from these concerns so that you can otherwise concentrate on business logic."

Why use Unit of Work?

Again Martin Fowler says,"When you're pulling data in and out of a database, it's important to keep track of what you've changed; otherwise, that data won't be written back into the database. Similarly you need to insert new objects you create and remove any objects you delete.

You can change the database with each change to your object model, but this can lead to many very small database calls, which ends up being very slow. Furthermore it requires you to have a transaction open for the entire interaction, which is impractical if you have a business transaction that spans multiple requests. The situation is even worse if you need to keep track of the objects you've read so you can avoid inconsistent reads.

A Unit of Work keeps track and takes responsibility of everything you do during a business transaction that can affect the database. When you're done, it figures out everything that needs to be done to alter the database as a result of your work."

You see I don't need to concentrate much on theory, we already have great definitions, all we needed is to stack them in a correct format.

Using the Unit of Work

One of the best ways to use the Unit of Work pattern is to allow disparate classes and services to take part in a single logical transaction. The key point here is that you want the disparate classes and services to remain ignorant of each other while being able to enlist in a single transaction. Traditionally, you've been able to do this by using transaction coordinators like MTS/COM+ or the newer System.Transactions namespace. Personally, I prefer using the Unit of Work pattern to allow unrelated classes and services to take part in a logical transaction because I think it makes the code more explicit, easier to understand, and simpler to unit test (also from MSDN).

Creating Generic Repository

Cut the Redundancy

Step 1 : Open up our existing MVC3 application created in Part 5 in Visual Studio.

Step 2 : Right-click the Learning MVC project folder and create a folder named GenericRepository and add a class named GenericRepository.cs to that folder.

The code of the GenericRepository.cs class is as follows:

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Entity;
using System.Linq;
using System.Linq.Expressions;
namespace LearningMVC.GenericRepository
{
public class GenericRepository<TEntity> where TEntity : class
{
internal MVCEntities context;
internal DbSet<TEntity> dbSet;
public GenericRepository(MVCEntities context)
{
this.context = context;
this.dbSet = context.Set<TEntity>();
}
public virtual IEnumerable<TEntity> Get()
{
IQueryable<TEntity> query = dbSet;
return query.ToList();
}
public virtual TEntity GetByID(object id)
{
return dbSet.Find(id);
}
public virtual void Insert(TEntity entity)
{
dbSet.Add(entity);
}
public virtual void Delete(object id)
{
TEntity entityToDelete = dbSet.Find(id);
Delete(entityToDelete);
}
public virtual void Delete(TEntity entityToDelete)
{
if (context.Entry(entityToDelete).State == EntityState.Detached)
{
dbSet.Attach(entityToDelete);
}
dbSet.Remove(entityToDelete);
}
public virtual void Update(TEntity entityToUpdate)
{
dbSet.Attach(entityToUpdate);
context.Entry(entityToUpdate).State = EntityState.Modified;
}
}
}

We can see, we have created the generic methods and the class as well is generic, when instantiating this class we can any model on which the class will work as a repository and serve the purpose.

TEntity is any model/domain/entity class.

MVCEntities is our DBContext as discussed in earlier parts.

Step 3 : Implementing UnitOfWork: Create a folder named UnitOfWork under the LearningMVC project, and add a class UnitOfWork.cs to that folder.

The code of the class is as follows:

using System;
using LearningMVC.GenericRepository;
namespace LearningMVC.UnitOfWork
{
public class UnitOfWork : IDisposable
{
private MVCEntities context = new MVCEntities();
private GenericRepository<User> userRepository;
public GenericRepository<User> UserRepository
{
get
{
if (this.userRepository == null)
this.userRepository = new GenericRepository<User>(context);
return userRepository;
}
}
public void Save()
{
context.SaveChanges();
}
private bool disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!this.disposed)
{
if (disposing)
{
context.Dispose();
}
}
this.disposed = true;
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
}
}

We see the class implements the IDisposable interface for objects of this class to be disposed.

We create an object of DBContext in this class, note that earlier it was used to be ed in the Repository class from a controller.

Now it's time to create our User Repository. We see in the code itself that, simply a variable named userRepository is declared as private GenericRepository<User> userRepository; of type GenericRepository serving User entity to the TEntity template.

Then a property is created for the same userRepository variable in a very simplified manner as in the following:

public GenericRepository<User> UserRepository
{
get
{
if (this.userRepository == null)
this.userRepository = new GenericRepository<User>(context);
return userRepository;
}
}

In other words, merely 6-7 lines of code. Guess what? Our UserRepository is created.

(taken from google)

You see, it was as simple as that, you can create as many repositories as you want by just creating simple properties, and there is no need to create separate classes. And now you can complete the rest of the story by yourself. Confused????,Yes its DBOperations, let's do it.

Step 4 : In MyController, declare a variable unitOfWork as:

private UnitOfWork.UnitOfWork unitOfWork = new UnitOfWork.UnitOfWork();

Now this unitOfWork instance of the UnitOfWork class holds all the repository properties. If we press "." after it then it will show the repositories.So we can choose any of the repositories created and perform CRUD operations on them. For example our Index action:

public ActionResult Index()
{
var userList = from user in unitOfWork.UserRepository.Get() select user;
var users = new List<LearningMVC.Models.UserList>();
if (userList.Any())
{
foreach (var user in userList)
{
users.Add(new LearningMVC.Models.UserList() { UserId = user.UserId, Address = user.Address, Company = user.Company, FirstName = user.FirstName, LastName =
user.LastName, Designation = user.Designation, EMail = user.EMail, PhoneNo = user.PhoneNo });
}
}
ViewBag.FirstName = "My First Name";
ViewData["FirstName"] = "My First Name";
if(TempData.Any())
{
var tempData = TempData["TempData Name"];
}
return View(users);
}

Here,

unitOfWork.UserRepository - Accessing UserRepository.

unitOfWork.UserRepository.Get() - Accessing Generic Get() method to get all users.

Earlier we had the MyController constructor like:

public MyController()
{
this.userRepository = new UserRepository(new MVCEntities());
}

We now do not need to write that constructor, in fact you can remove the UserRepository class and interface we created in the fifth part of Learning MVC.

I hope you can write the actions for the rest of the CRUD operations as well.

Details

public ActionResult Details(int id)
{
var userDetails = unitOfWork.UserRepository.GetByID(id);
var user = new LearningMVC.Models.UserList();
if (userDetails != null)
{
user.UserId = userDetails.UserId;
user.FirstName = userDetails.FirstName;
user.LastName = userDetails.LastName;
user.Address = userDetails.Address;
user.PhoneNo = userDetails.PhoneNo;
user.EMail = userDetails.EMail;
user.Company = userDetails.Company;
user.Designation = userDetails.Designation;
}
return View(user);
}

Create:

[HttpPost]
public ActionResult Create(LearningMVC.Models.UserList userDetails)
{
try
{
var user = new User();
if (userDetails != null)
{
user.UserId = userDetails.UserId;
user.FirstName = userDetails.FirstName;
user.LastName = userDetails.LastName;
user.Address = userDetails.Address;
user.PhoneNo = userDetails.PhoneNo;
user.EMail = userDetails.EMail;
user.Company = userDetails.Company;
user.Designation = userDetails.Designation;
}
unitOfWork.UserRepository.Insert(user);
unitOfWork.Save();
return RedirectToAction("Index");
}
catch
{
return View();
}
}

Edit:

public ActionResult Edit(int id)
{
var userDetails = unitOfWork.UserRepository.GetByID(id);
var user = new LearningMVC.Models.UserList();
if (userDetails != null)
{
user.UserId = userDetails.UserId;
user.FirstName = userDetails.FirstName;
user.LastName = userDetails.LastName;
user.Address = userDetails.Address;
user.PhoneNo = userDetails.PhoneNo;
user.EMail = userDetails.EMail;
user.Company = userDetails.Company;
user.Designation = userDetails.Designation;
}
return View(user);
}
[HttpPost]
public ActionResult Edit(int id, User userDetails)
{
TempData["TempData Name"] = "Akhil";
try
{
var user = unitOfWork.UserRepository.GetByID(id);
user.FirstName = userDetails.FirstName;
user.LastName = userDetails.LastName;
user.Address = userDetails.Address;
user.PhoneNo = userDetails.PhoneNo;
user.EMail = userDetails.EMail;
user.Company = userDetails.Company;
user.Designation = userDetails.Designation;
unitOfWork.UserRepository.Update(user);
unitOfWork.Save();
return RedirectToAction("Index");
}
}

Delete:

public ActionResult Delete(int id)
{
var user = new LearningMVC.Models.UserList();
var userDetails = unitOfWork.UserRepository.GetByID(id);
if (userDetails != null)
{
user.FirstName = userDetails.FirstName;
user.LastName = userDetails.LastName;
user.Address = userDetails.Address;
user.PhoneNo = userDetails.PhoneNo;
user.EMail = userDetails.EMail;
user.Company = userDetails.Company;
user.Designation = userDetails.Designation;
}
return View(user);
}
[HttpPost]
public ActionResult Delete(int id, LearningMVC.Models.UserList userDetails)
{
try
{
var user = unitOfWork.UserRepository.GetByID(id);
if (user != null)
{
unitOfWork.UserRepository.Delete(id);
unitOfWork.Save();
}
return RedirectToAction("Index");
}
catch
{
return View();
}
}

Note: Images are taken from Google images.

Conclusion

We now know how to make generic repositories too, and perform CRUD operations using it.

We have also learned the UnitOfWork pattern in detail. Now you are qualified and confident enough to apply these concepts in your enterprise applications. This was the last part of this MVC series, let me know if you wish to discuss any topic in particular or we can also start another series as well.

Read more:

Other Series

My other series of articles:

For more informative articles visit my Blog.

Happy Coding.

11 Comments

Join the conversation! Your thoughts help the community grow.

Debasis Saha10y ago
Nice article..
- Akhil Mittal10y ago
  Thanks
Kuppurasu Nagaraj10y ago
Nice Sharing..
- Akhil Mittal10y ago
  Thanks
Rahul Kumar Saxena10y ago
Good Show
- Akhil Mittal10y ago
  Thanks
Gowtham Rajamanickam10y ago
nice article..
- Akhil Mittal10y ago
  Thanks
Akhil Mittal13y ago
I disagree.The provided code is an architecture,you can always extend it.and for your SQL query,there are where clause predicates in LINQ.You can create a generic method in Generic Repository class which contains a where clause predicate as a parameter.Try it.
Ionut Corneanu13y ago
This solution looks nice in theory but it is impractical in practice. You shouldn't get all the entities in memory and then filter them. Also, what if you have a complex query, say you want to get all users that have their Firstname = "John"? What will you do? Get all users in memory and then filter them? What if you have 50 thousands users? You will get them all?
ad coders13y ago
Detailed Presentation. Good One.