Repository Pattern in MVC3 Application With Entity Framework: Part 5

Introduction

In our last four articles, we learned nearly everything about how to create a MVC application and how to communicate with a database using the same application.

In the third part of Learning MVC, we learned how to communicate between a MVC application and database using the EntityFramework, so referring to the same context, in this article I'll focus on how to implement a Repository Pattern in the same MVC application, therefore moving ahead a step towards an architectural approach of developing an enterprise application.

Our Roadmap

Just as a reminder of our full roadmap towards learning MVC:

Pre-requisites

There are a few pre-requisites before we start with the article, as in the following:

We have a running sample application that we created in the third part of the article series.
We have the EntityFramework 4.1 package or DLL on our local file system.
We understand how a MVC application is created.

Repository Pattern

Very few authors explain the concept, and instead jump directly to the practical implementation of the pattern. So, let us first understand what the repository pattern is and why we should use it.

In simple terms, a repository basically works as a mediator between our business logic layer and our data access layer of the application. Sometimes it would be troublesome to expose the data access mechanism directly to the business logic layer, it may result in redundant code for accessing data for similar entities or it may result in code that is hard to test or understand. To overcome these kinds of issues, and to write an interface driven and test driven code to access data, we use the Repository Pattern. The repository makes queries to the data source for the data and thereafter maps the data from the data source to a business entity/domain object and finally persists the changes in the business entity to the data source. According to the MSDN, a repository separates the business logic from the interactions with the underlying data source or web service. The separation between the data and business tiers has the following three benefits:

It centralizes the data logic or web service access logic.
It provides a substitution point for the unit tests.
It provides a flexible architecture that can be adapted as the overall design of the application evolves.

When we use the Entity Framework, as we did in our last application created, we were calling the Entity Framework class object in the controller class for accessing the entity classes. Now we can say that that system was somewhat a tightly coupled system. To overcome this situation, as we discussed, we'll implement the Repository Pattern.

In the Repository, we write our entire business logic of CRUD operations using Entity Framework classes, that will not only result in meaningful test driven code but will also reduce our controller code of accessing data.

Creating Repository

The creation of the Repository is not as tough as it sounds, once you implement this on your own, you'll love it.

Step 1: Open our existing MVC3 application in Visual Studio, that we created in the third part to interact with the database using the Entity Framework.

Step 2: Create a folder named Repository and add an interface to that folder named IUserRepository , this interface we derived from the IDisposable type of interface.

We'll declare methods for CRUD operations on the user entity class over here, you can choose the names of the methods as you prefer, but those should be easy to understand and follow.

Like as I used in the following code of my interface:

using System;
using System.Collections.Generic;
namespace LearningMVC.Repository
{
public interface IUserRepository:IDisposable
{
IEnumerable<User> GetUsers();
User GetUserByID(int userId);
void InsertUser(User user);
void DeleteUser(int userId);
void UpdateUser(User user);
void Save();
}
}

We can see that each method name signifies a particular CRUD operation on user entity.

User Entity is the same entity we generated in the Model.tt class in Part 3 of learning MVC, remember?

Step 3: Extract a class from that interface and call it "UserRepository". This UserRepository class will implement all the methods of that interface, but using the Entity Framework. Now for the use of our DBContext class MVCEntities, we already have this class in our existing solution, so we don't need to touch this class, instead we simply write our business logic in the interface methods implemented in UserRepository Class.

using System;
using System.Collections.Generic;
using System.Data;
using System.Linq;
namespace LearningMVC.Repository
{
public class UserRepository:IUserRepository
{
private MVCEntities context;
public UserRepository(MVCEntities context)
{
this.context = context;
}
public IEnumerable<User> GetUsers()
{
return context.Users.ToList();
}
public User GetUserByID(int userId)
{
return context.Users.Find(userId);
}
public void InsertUser(User user)
{
context.Users.Add(user);
}
public void DeleteUser(int userId)
{
User user = context.Users.Find(userId);
context.Users.Remove(user);
}
public void UpdateUser(User user)
{
context.Entry(user).State = EntityState.Modified;
}
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);
}
}
}

And do the following inside the solution.

Interface:

Class:

90% of the job is now done. Now the only thing left is to use this repository in our controller.

It is unnecesarry to explain how you'll call the repository inside the controller, since you now know how to treat our controller, but still let's do it for once.

Step 4: Go to the controller, declare the IUserRepository reference, and in the constructor initialize the object with the UserRepository class, ing MVCEntities to the constructor as a parameter we defined in our UserRepository class:

#region Private member variables...
private IUserRepository userRepository;
#endregion
#region Public Constructor...
/// <summary>
/// Public Controller to initialize User Repository
/// </summary>
public MyController()
{
this.userRepository = new UserRepository(new MVCEntities());
}
#endregion

In the solution this will look like:

Step 5: Now for all the actions of the controller in which we were using the Entity Framework context directly, we replace the calling logic by the new userRepository object, and call methods defined in the repository class.

Like, in Index controller, where we show the list of users, we do:

var userList = from user in userRepository.GetUsers() 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 });
}
}

We can see the earlier code remained the same, except a layer has been introduced between the Entity Framework data access layer and the business logic, and the controller now only uses that abstracted layer to communicate with the database.

Similarly for other Actions of the controller.

Details :

Create:

Edit:

Delete:

Step 6: Run the application and we see the application running as it was earlier.

Now it's party time.

Conclusion

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

Now we can visualize how useful the pattern is and how it solved our issues of tight coupling and resulted in an appropriate architecture.

As per the MSDN, use the Repository Pattern to do one or more of the following objectives:

You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
You want to implement and centralize a caching strategy for the data source.
You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
You want to apply a domain model to simplify complex business logic.

And I fully agree with that, but is our application made using the pattern appropriately? What if there are 100's of Repositories that need to be created? What if we have 100's of entities? Do we create Repositories for all of them, resulting in a mess and code redundancy? The answer is a big NO. In my next and last article of the series, we'll learn how to create a Generic Repository to serve the purpose of multiple Entities. The source code of this article and existing article, in other words Part 3 along with database scripts has been attached, you can download and run the solution, and drop me a question in case you feel like it. I'll be happy to answer.

Read more:

Other Series

My other series of articles:

For more informative articles visit my Blog.

Happy Coding :-).

7 Comments

Join the conversation! Your thoughts help the community grow.

Jatinder Kaur8y ago
Very well expained
- Akhil Mittal8y ago
  Thanks for reading
Chetan Gupta9y ago
Sir,in my case I have ran Install-Package Unity.WebAPI but I am getting the error. The type or namespace name 'UnitOfWork' could not be found
Rajeev Punhani10y ago
Nicely explained especially repository pattern concept.
- Akhil Mittal10y ago
  Thanks
ad coders13y ago
Nice Article Series.Part 6???
- Akhil Mittal10y ago
  Thanks