Repository Pattern in .NET Core

A couple of years ago, I wrote about the Repository and Unit of Work pattern. Although this post is quite old and not even .NET Core, I get many questions about it. Since the writing of the post, .NET core matured and I learned a lot about software development. Therefore, I wouldn’t implement the code as I did back then. Today, I will write about implementing .the repository pattern in .NET core

Why I am changing the Repository Pattern in .NET Core

Entity Framework Core already serves as unit of work. Therefore you don’t have to implement it yourself. This makes your code a lot simpler and easier to understand.

The Repository Pattern in .NET Core

For the demo, I am creating a simple 3-tier application consisting of controller, services, and repositories. The repositories will be injected into the services using the built-in dependency injection. You can find the code for the demo on GitHub.

In the data project, I have my models and repositories. I create a generic repository that takes a class and offers methods like get, add, or update.

Implementing the Repositories

This repository can be used for most entities. In case one of your models needs more functionality, you can create a concrete repository that inherits from Repository. I created a ProductRepository which offers product-specific methods:

The ProductRepository also offers all generic methods because its interface IProductRepository inherits from IRepository:

The last step is to register the generic and concrete repositories in the Startup class.

The first line registers the generic attributes. This means if you want to use it in the future with a new model, you don’t have to register anything else. The second and third line register the concrete implementation of the ProductRepository and CustomerRepository.

Implementing Services which use the Repositories

I implement two services, the CustomerService and the ProductService. Each service gets injected a repository. The ProductServices uses the IProductRepository and the CustomerService uses the ICustomerRepository;. Inside the services, you can implement whatever business logic your application needs. I implemented only simple calls to the repository but you could also have complex calculations and several repository calls in a single method.

Implementing the Controller to test the Application

To test the application, I implemented a really simple controller. The controllers offer for each service method a parameter-less get method and return whatever the service returned. Each controller gets the respective service injected.

When you call the create customer action, a customer object in JSON should be returned.

Test the creation of a customer

Use the database

If you want to use the a database, you have to add your connection string in the appsettings.json file. My connection string looks like this:

By default, I am using an in-memory database. This means that you don’t have to configure anything to test the application

I also added an SQL script to create the database, tables and test data. You can find the script here.

Conclusion

In today’s post, I gave my updated opinion on the repository pattern and simplified the solution compared to my post a couple of years ago. This solution uses entity framework core as unit of work and implements a generic repository that can be used for most of the operations. I also showed how to implement a specific repository, in case the generic repository can’t full fill your requirements. Implement your own unit of work object only if you need to control over your objects.

You can find the code for the demo on GitHub.