ASP.NET CORE 2.2.1 Hosting – Implement Repository Pattern In .NET

The intention of this post is to explain about the Repository pattern and how it’s useful in enterprise applications.

  • Introduction
  • Why use Repository
  • Misconceptions
  • Implementation
  • Conclusion
  • Source Code


The repository pattern is an abstraction layer between your database and business layer. The idea behind implementing repository pattern is to hide the data persistence details. You data may be persisted by using some database server like MySQL or Oracle or it may be by using some flat file, Excel file or any NoSQL database like MongoDB or CouchDB etc.

Why use Repository

If you want to achieve the listed functionality in your application then you can go for the repository pattern.

Loosely coupled
To make the application loosely coupled and remove the specific database dependency from the application.
Unit Testing
Increase testability of application, there are so many frameworks available to mock the repositories to write the unit test cases.
Dependency Injection
Utilize the power of dependency injections in your application. Since you are implementing an interface for the repository pattern, you can make use of DI container to create a repository object for you.
Clean Code
Since you are using repositories for your database operations, you don’t need to spoil the code and write the database related operations all over the place.
Separation of Concern
The repository also supports the target of accomplishing a clean separation and one-way dependency between the domain and data mapping layers.

If you have more then one persistence technology then you should be the perfect applicant for implementing the repository pattern.

Misconceptions about repository pattern

There are so many misconceptions among people about implementing the repository pattern.

A repository is a replacement for data access layer.

Repository pattern should not be used if you are using Entity Framework.


Enough talking now; let’s jump into the practical or demo application. I will be using a simple C# application to demonstrate the repository pattern.

I have created an MVC application with the default template. In this application database, operations are performed inside the controller using entity framework DbContext.

Let’s create the Customer class with a few properties: Id, Name, and Address.

Now, let’s create the CustomerController class which will have all CRUD operations for the customer model class.

Customer Controller class uses ApplicationDbContext for performing all database operations. Running this Demo application will work like a charm with no issue. I can add, update and delete the customer.

Now let’s talk about the problems we will face with this approach.

By seeing the code we can identify there is no separation of concern.

An application is tightly coupled with the Entity Framework.

If you want to move from Entity framework to some other ORM tool like NHibernate it’s going to be a big mess and will require a lot of time and code changes.

Let’s say you want to add softDelete column for all the tables. With this approach, you have to do this many times before you make any changes.

Let’s start with the repository pattern implementation to overcome these situations.

Let’s divide the project into two parts, web and DAL, and move the database related stuff to a different project and call that project Repository.Demo.DAL.

When it comes to the separation of concern the first thing that comes to mind is designing the contract or interface.

So let’s create the interface called IRepository. This interface uses a generic parameter that should be the class type. So you can implement the Repository for each of your entity classes.

As you can see in the IRepository interface we have defined the commonly used CRUD operation methods.You can extend this as per your requirement like adding methods for searching method by Id, Name etc.

Now let’s create the implementation class for IRepository interface. I am calling this class EfCustomerRepository because this Repository is for customer Entity and we are using Entity Framework for the backend database so use Ef as the prefix.

Now Reference the Repository.Demo.DAL project to the Web Project. And make changes to the CustomerController class to use IReposiroty instead of directly using ApplicationDbContext class.

After making changes in CustomerController class:

Great! Now you are using repository pattern in your application. However, there is a lot of room for enhancement like implementing the generic repository, repository with the unit of work, and using the dependency injections in the application. I am going to post more articles as the continuation of this repository pattern implementation where we will try to achieve all these enhancements.