Learn Repository Design Pattern With .Net Core

Introduction

Repository is something where we can store some data/info. From an application standpoint, it's nothing but a database. We have database providers like SQL or Oracle or MongoDb etc. When we say repository, it's nothing but a usual class that encapsulates data access layer operations. Inside this class we can define logics to do CRUD operation and we can even change our database provider based on our need. In short, business logic layer and data access layer can work independently and become loosely coupled layers. We are going to use Repository design pattern to meet loose coupling of business and data access layer.

Before I start, let's take a look at the usual project structure.

Here UI Layer refers to any client project like Angular / React / .net core Razor views.

BLL ( Business logic layer) refers to controllers or application specific BLL class.

DAL (Data access layer) refers to class/ component that manages application database operations. We can call it as repository.

Prerequisite

I am going to use .Net core (with razor view) and SQL database provider. Please choose a .Net core project of your choice.
I will use code first approach. Hence please install Microsoft.EntityFrameworkCore from NuGet .

What are we trying to achieve?

Loose coupling between BLL and DAL.
An application independent of database provider.

So let's begin. I have defined a folder named "Database" where I am going to hold all database related operations. If you wish, you may create a separate class library project.

Let's add Order and Item model class to do database operation.

public class Order
{
[Key]
public int Id { get; set; }
public string UserName { get; set; }
[EmailAddress]
public string EmailId { get; set; }
public string DeliveryAddress { get; set; }
[Required]
public int PhoneNo { get; set; }
[Required]
public List<Item> Items { get; set; }
}

public class Item
{
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
}

Since we are planning to change database providers, let's define connection strings in appsettings.json as below.

"ConnectionStrings": {
"AppDb": "Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=master;Integrated Security=True;Database=SqlDb",
"OracleDb": "Data Source=(localdb)\\OracleDB;Initial Catalog=master;Integrated Security=True;Database=OracleDb"
}

Now let's add AppDbContext class for database operation as per entity framework standard. Here is the code.

public class AppDbContext : DbContext
{
public DbSet<Order> Orders { get; set; }
public AppDbContext(DbContextOptions<AppDbContext> options):base(options)
{
}
}

Now to meet loose coupling, we will have to define an interface called "IRepository" and we will expose this interface to the business logic layer. Then we will create its concrete classes as "SqlRepository", "OracleRepository" and "InMemoryRepository". As the name suggests, SqlRepository will connect to SQL data provider, OracleRepository will connect to Oracle data provider and InMemoryRepository, we will save data in memory (no database provider). Here is the code.

public interface IRepository
{
void AddOrder(Order order);
List<Order> GetOrders();
Order GetOrder(int orderId);
}

Let's implement concrete classes as below.

public class InMemoryRepository : IRepository
{
private List<Order> orders;
public InMemoryRepository()
{
//default value initialization.
this.orders = new List<Order>() {
new Order(){
Id= 1,
UserName="A",
EmailId="[email protected]",
DeliveryAddress="some address",
Items=new List<Item>(){
new Item() {
Id= 1, Name="Item1",
Description="Item1 Desc"
},
new Item() {
Id= 2, Name="Item2",
Description="Item2 Desc"
}
}
}
};
}
public void AddOrder(Order order)
{
orders.Add(order);
}
public Order GetOrder(int orderId)
{
return orders.Find(o => o.Id == orderId);
}
public List<Order> GetOrders()
{
return orders;
}
}

When we point our application to InMemoryRepository, application will store order details in memory. We aren't going to use any external database provider and hence the name InMemoryRepository.

public class SqlRepository : IRepository
{
private AppDbContext dbContext;
public SqlRepository(AppDbContext appDbContext)
{
dbContext = appDbContext;
}
public void AddOrder(Order order)
{
dbContext.Orders.Add(order);
dbContext.SaveChanges();
}
public Order GetOrder(int orderId)
{
return dbContext.Orders.First(order => order.Id == orderId);
}
public List<Order> GetOrders()
{
return dbContext.Orders.ToList();
}
}

When we point our application to use SqlRepository, the application will save data in SQL database . As you can see we are using entity framework for database operation.

Similarly, we can define OracleRepository class the same as SqlRepository class. I am skipping its implementation for now. Here is the skeleton structure of it.

public class OracleRepository : IRepository
{
public void AddOrder(Order order)
{
//implementation to add order
}
public Order GetOrder(int orderId)
{
//implementation
}
public List<Order> GetOrders()
{
//implementation
}
}

Our project folder structure looks like this so far.

Object Diagram of the repository structure,

Now the obvious question is, where have we defined which concrete implementation we should use. In .Net core, we should register IRepository interface implementation in ConfigureServices() method , inside Startup.cs. Once we host .Net core project the application will execute ConfigureServices() before serving any request. If we register implementation for IRepository as SqlRepository, all database operations will occur on SQL database. Similarly it can point to other databases as well. Here is the code for it.

public void ConfigureServices(IServiceCollection services)
{
string connectionString = config.GetConnectionString("AppDb");
services.AddDbContextPool<AppDbContext>(options => options.UseSqlServer(connectionString));
services.AddScoped<IRepository, SqlRepository>();
}

Now let's see whether it's working as expected or not. Here instead of creating any UI for entering data, I am going to hard code some data for addition, in index action of home controller. In real-time applications, we will have UI to enter all data. Just to save time I am going to hard code it. If you wish, you can create your own UI for manual data entry as well.

Before trying to do any CRUD operation, first we need to inject IRepository interface in our HomeController. HomeController is the BLL for us. So here we can see BLL has reference to IRepository, but it is not aware of its concrete implementation. Whether the application points to SqlRepository /InMemoryRepository / OracleRepository as definition of IRepository, BLL logic is independent and hence we have achieved loose coupling between BLL and DAL.

Here is the code of HomeController.

public class HomeController : Controller
{
private IRepository Repository;
public HomeController(IRepository repository)
{
Repository = repository;
}
public IActionResult Index()
{
var order = new Order()
{
UserName = "Ram",
EmailId = "[email protected]",
DeliveryAddress = "address",
Items = new List<Item>(){
new Item() {
Name="Book",
Description="book Desc"
},
new Item() {
Name="Pen",
Description="pen Desc"
}
}
};
Repository.AddOrder(order);
var allOrders = Repository.GetOrders();
return View();
}
}

Let's run our application and see whether we are able to save data or not. Note currently the application is pointing to SqlRepository.

Output

As you can see record is getting saved.

If you are wondering why Id is 6, it's because I have tried saving some data before writing this article.

Now let's try to point our application to InMemory repository. I am not going to change any code in HomeController. All we have to change is, a few lines in ConfigureServices method of Startup.cs file. Here is the code.

public void ConfigureServices(IServiceCollection services)
{
services.AddScoped<IRepository, InMemoryRepository>();
}

By adding the above line of code, we are telling the application to use In-memory repository. Here SQL database is no longer linked with our application.

Output

Here we see count 2. It's because we have defined one order inside its constructor.

Similarly, we can define implementation for OracleRepository too. I am not doing it at the moment as i don't have Oracle installed in my machine.

Advantage

Loose coupling between business logic layer and data access layer.
We can change database provider with minimal code change at any given point of time.
We can centralise database code in once project/ component.
We can write unit test for business logic without spying on DAL.
We can reuse database access code , if we define generic CRUD operations.

Summary

In this article we have learned how to set up repository pattern in .Net core application. By doing so we can change our database provider repository at any given point of time , with minimal code change. We can define all database related operations in one place and it can be reused. Using this design pattern makes BLL independent of DAL.

I hope this article is useful for you. I am always open for any suggestions or any improvement. Thanks for finding some time to read this article.