Professional Documents
Culture Documents
in
http://csharppulse.blogspot.in/2013/09/learning-mvc-part-5repository-pattern.html
Introduction
In our last four articles, we learnt almost everything about how to create an MVC application and how to
communicate with database using the same application.
In the third part of learning MVC, we learnt communication between MVC application and database using
EntityFramework, so I am referring to the same context. In this article, Ill focus on how to implement a
Repository Pattern in the same MVC application, therefore moving ahead a step towards architectural approach
of developing an enterprise application.
Our Roadmap
Just to remind you of our full roadmap towards learning MVC:
Pre-requisites
There are a few pre-requisites before we start with the article:
1. We have running sample application that we created in the third part of the article series.
2. We have EntityFramework 4.1 package or DLL on our local file system.
3. We understand how the MVC application is created.
Repository Pattern
Very few authors explain the concept and jump directly over the practical implementation of the pattern. So, first
let us understand what is repository pattern? Why should we 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
business logic layer, it may result in redundant code for accessing data for similar entities or it may result in a
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 Repository Pattern. The repository makes queries to the data source for
the data, thereafter maps the data from the data source to a business entity/domain object, finally and persists the
changes in the business entity to the data source. According to 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 three benefits:
Creating Repository
Creating Repository is not as tough at it sounds to be, once you implement this by your own, youll love it.
Step 1: Open up our existing MVC3 application in Visual Studio, that we created in the third part to interact with
database with the help of Entity Framework.
Step 2: Create a folder named Repository and add an Interface to that folder named IUserRepository, this
interface we derive from IDisposable type of interface.
Well declare methods for CRUD operations on User entity class over here, you can choose the names of the
method as per your choice, but those should be easy to understand and follow.
Like I used in the below 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 each method name signifies particular CRUD operation on User entity.
User Entity is the same entity we generated in Model.tt class in Part3 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 with the help of Entity Framework. Now here comes the use of
our DBContextclass MVCEntities, we already have this class in our existing solution, so we dont have to
touch this class, simply, write our business logic in the interface methods implemented in UserRepository
class:
using
using
using
using
System;
System.Collections.Generic;
System.Data;
System.Linq;
namespace LearningMVC.Repository
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 inside the solution:
Interface
Class
90% of the job is done now. Now the only thing left is to use this repository in our controller.
This is needless to explain how youll call repository inside the controller, as 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
withUserRepository class, passing MVCEntities to the constructor as parameter we defined in
UserRepositoryclass:
#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 Entity Framework context directly, we
replace the calling logic by the created userRepository object, and call methods defined in repository
class.
Like, in Index controller, where we show the list of users, we do:
Details
Create
Edit
Delete
Step 6: Run the application, and we see the application running as it was earlier:
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 MSDN, Use the Repository pattern to achieve 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 to it, but has our application made use of the pattern appropriately? What if there are 100s of
Repositories that need to be created? What if we have 100s 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, well
learn how to create a Generic Repository to serve the purpose of n number of Entities. The source code of this
article and existing article, i.e., 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. Ill be happy to answer.
For more informative articles,visit my blog A Practical Approach .
Happy coding! :-)