.NET 6.0 - Clean Architecture using Repository Pattern and Dapper with Logging and Unit Testing

In this article, we will learn about clean architecture and will walk you through a sample CRUD API in .NET 6.0.

We will use the following tools, technologies, and frameworks in this sample:

• Visual Studio 2022 and .NET 6.0
• C#
• MS SQL DB
• Clean Architecture
• Dapper (mini ORM)
• Repository Pattern
• Unit of Work
• Swagger UI
• API Authentication (Key Based)
• Logging (using log4net)
• Unit Testing (MSTest Project)

Before starting with the sample app, let us understand the clean architecture and its benefits.

The goal of software architecture is to minimize the human resources required to build and maintain the required system. ― Robert C. Martin, Clean Architecture

Clean Architecture explained:

Clean Architecture is the system architecture guideline proposed by Robert C. Martin also known as Uncle Bob. It is derived from many architectural guidelines such as Hexagonal Architecture, Onion Architecture, etc.

• The main concept of clean architecture is that the core logic of the application is changed rarely so it will be independent and considered core.
• The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards and nothing in an inner circle can know anything at all about something in an outer circle.
• By separating the software into layers, and conforming to The Dependency Rule, you will create an intrinsically testable system, with all the benefits that imply. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.
• In clean architecture, the domain and application layers remain in the center of the design which is known as the core of the application.
  • The domain layer contains enterprise logic, and the application layer contains business logic.
  • Enterprise logic can be shared across many related systems, but business logic is not sharable as it is designed for specific business needs.
  • If you do not have an enterprise and are just writing a single application, then these entities are the business objects of the application.

Advantages of clean architecture:

• Frameworks Independent - The architecture does not depend on the existence of some library of feature-laden software. This allows you to use such frameworks as tools.
• UI Independent - It is loosely coupled with the UI layer. So, you can change UI without changing the core business.
• Independent of Database - You can swap out SQL Server or Oracle, for Mongo, Bigtable, CouchDB, or something else. Your business rules are not bound to the database.
• Highly maintainable - It is following the separation of concern.
• Highly Testable - Apps built using this approach, especially the core domain model and its business rules, are extremely testable.

So now got an understanding of clean architecture. Before starting the sample API let us briefly review the Dapper.

Dapper explained:

• Dapper is a simple Object Mapper or a Micro-ORM responsible for mapping between database and programming language.
• Dapper was created by the Stack Overflow team to address their issues and open-source it. Dapper used at Stack Overflow itself showcases its strength.
• It drastically reduces the database access code and focuses on getting database tasks done instead of being full-on ORM.
• It can be integrated with any database such as SQL Server, Oracle, SQLite, MySQL, PostgreSQL, etc.
• If DB is already designed, then using Dapper is an optimal and efficient option.
• Performance: Dapper is faster at querying data compared to the performance of the Entity Framework. This is because Dapper works directly with the RAW SQL and hence the time delay is relatively less.

Along with Dapper in this article, we will use Repository Pattern and Unit of Work and show you how Dapper can be used in an ASP.NET 6.0 API following Repository Pattern and Unit of Work.

Solution and Project setup:

First of all, create a new table that’ll be used to perform the CRUD operation. You can use the scripts shared under the CleanArch.Sql/Scripts folder of the code sample.

Once our back end is ready, Open Visual Studio 2022 and create a blank solution project, and name it to CleanArch.

Set Up Core Layer: Under the solution, create a new Class Library project and name it CleanArch.Core.

• Add a new folder Entities and add a new entity class with the name Contact.

One thing to note down here is, The Core layer should not depend on any other Project or Layer. This is very important while working with Clean Architecture.

Set Up Application Layer: Add another Class Library Project and name it CleanArch.Application.

• Add a new folder Application and under this, we will define the interfaces that will be implemented at another layer.
• Create a generic IRepository interface and define the CRUD methods.

• Add a reference to the Core project, The Application project always depends only on the Core Project.
• After that add a Contact specific repository (IContactRepository), and inherit it from IRepository
• Also, create a new interface, and name it IUnitOfWork since we will be using Unit of Work in our implementation.

• As we are also implementing the logging, so add a ILogger interface and add methods for different log levels.

Set Up Logging: Add a new Class Library Project (CleanArch.Logging)

• We will be using the Log4Net library for logging, hence install the log4net package from the Nuget Package Manager.
• Add a reference to the Application project and after that add a new class Logger and implement the ILogger interface.

Set Up SQL Project: Add a new Class Library Project (CleanArch.Sql). We’ll be using this project to manage the Dapper Queries.

• Add a new folder Queries and add a new class under it ContactQueries (to manage dapper queries for the Contact object).

• Besides that, Scripts folder is added that contains prerequisite scripts of table used in the sample.

Set Up Infrastructure Layer: Since our base code is ready, now add a new Class Library Project and name it CleanArch.Infrastructure.

• Add the required packages to be used in this project.

Install-Package Dapper
Install-Package Microsoft.Extensions.Configuration
Install-Package Microsoft.Extensions.DependencyInjection.Abstractions
Install-Package System.Data.SqlClient

• Add the reference to projects (Application, Core, and Sql), and add a new folder Repository.
• After that let’s implement the IContactRepository interface, by creating a new class ContactRepository and injecting IConfiguration to get the connection string from appsettings.json

• Also, implement the IUnitOfWork interface, by creating a new class UnitOfWork

• Finally, register the interfaces with implementations to the .NET Core service container. Add a new class static ServiceCollectionExtension and add the RegisterServices method under it by injecting IServiceCollection.
• Later, we will register this under the API’s ConfigureService method.

Set up API Project: Add a new .NET 6.0 Web API project and name it CleanArch.Api.

• Add the reference to projects (Application, Infrastructure, and Logging), and add the Swashbuckle.AspNetCore package.
• Set up the appsettings.json file to manage the API settings and replace your DB connection string under ConnectionStrings section.

• Add log4net.config and add logging related settings under it. Make sure to set its Copy to Output Directory property to Copy Always.

• Configure Startup settings, such as RegisterServices (defined under CleanArch.Infrastructure project), configure log4net and add the Swagger UI (with authentication scheme).

• Remove the default controller/model classes and add a new class under Model (ApiResponse), to manage a generic response format for API responses.

• Add a new controller and name it AuthController, to implement Not Authorized implementation since we will be using the key-based authentication.

• Add AuthorizationFilter, as shown below to manage the API key-based authentication.
  • This allows authentication based on the main key and secondary keys.
  • We can add multiple secondary keys and we can turn on or off their usage from appsettings.
  • This will help to keep our main key safe and distribute the secondary keys to different clients on a need basis.

• Add a new controller and name it BaseApiController, this controller will contain the common implementation and will serve as a base controller for all other API controllers.

• Finally, add a new API controller to expose the Contact API by injecting an object type of IUnitOfWork and adding all the CRUD operations.

Set up a Test Project: Add a new MSTest Test project and name it CleanArch.Test and add the below packages.

Install-Package Microsoft.Extensions.Configuration
Install-Package MSTest.TestFramework
Install-Package MSTest.TestAdapter
Install-Package Moq

• After that create a new class ContactControllerShould and set up all the possible test cases, review the code of CleanArch.Test project for further understanding.

• Review the project structure in the solution explorer.
  

Build and Run Test Cases:

• Build the solution and run the code coverage, this will run all the test cases and show you the test code coverage.

Run and Test API:

Run the project and test all the CRUD API methods. (Make sure CleanArch.Api is set as a startup project)

• Swagger UI
  

• Running API without authentication throws error.
  

• Add API Authorization.
  

• POST - Add new record.
  

• GET - Get All records.
  

• PUT - Update the existing record.
  

• GET - Get single record.
  

• DELETE - Delete the existing record.
  

NOTE:

Check the entire source code here.

If you have any comments or suggestions, please leave them behind in the comments section below and If you've found a typo, a sentence that could be improved or anything else that should be updated on this blog post, please go directly to blog repository and open a new pull request with your changes.