N-Layer Architecture In A Multi-Project Solution

What is N-Layer architecture? How to apply it to a dotnet core ASP.NET application? In this article, C# is used, however, the concept is not platform nor language dependant. We tried to apply the concept of a three-layer architecture and encountered questions that are presented in this article. We discuss our findings and state the pros and cons of implementing the architecture. The goal is to simplify the process and understand how to concretely implement it in a project. In this article, to achieve an N-layer architecture we split a single project solution into a multi-project solution together with the use of Dependency Inversion and Dependency Injection.

What is N Layer Architecture

N-Layer (also called N-Tier) architecture enables the separation of functionality both physically and logically. The N stands for the number of layers the architecture consists of.

Figure 1

1. REST API — handles the API calls from e.g., a user.
2. Service layer — handles specific service call implementations.
3. Data Layer — handles data call implementations, e.g., MYSQL, MongoDB, etc…

To avoid circular dependencies layers should only be able to depend on layers directly next to them

Figure 1 consists of three layers, therefore, this represents a three-layer architecture. We see a separation in logic and responsibility for each layer. To avoid circular dependencies layers should only be able to depend on layers directly next to them. Observing figure 1 (with three layers), the API layer (layer one) should not be able to directly reference the data layer (layer three) — It should go in a sequence. The API layer may reference the service layer, which in turn, references the data layer.

It is possible to go even further to physically divide the functionality so that one layer may be deployed independently of another as for micro-services, however, this is a different topic and will not be discussed in this article.

So… How to apply it in in code?

Firstly, assume the following code project structure for a Quiz program:

Quiz
│   README.md
│   Quiz.sln
│
└───Quiz.Api
│       QuestionsController.cs
│       Startup.cs
│
└───Quiz.Services
│       QuestionsService.cs
│
└───Quiz.Data
        QuestionRepository.cs

In the above structure, the possible layers have already been separated by being moved into separate projects, but we could as well have started with a single project having all classes in the Quiz.Api.

Let us assume the project Quiz.Api has a simple QuestionsController with a GET endpoint/questions that, in turn, calls the QuestionService which calls the QuestionRepository that is responsible for accessing a database and fetching the stored questions.

The first question to answer is:

where should the concrete class be defined with a newclass object?

Each layer may have the responsibility for creating the next layer. An example:

1. The API Layer declares new QuestionsService()
2. The Service layer declares new QuestionRepository()

However, to reduce coupling we introduced Dependency Inversion to pass down an interface class to the next layer. This makes the class independent of the actual implementation, it only expects the class to be passed to its constructor. So now, the API layer is responsible to pass down a repository to the service class.

1. The API Layer declares
   new QuestionsService(IQuestionRepository)

But how can the service know which database to use when we pass down an interface? We need to instantiate the database before we pass it down, right?

//QuestionsController.cs
IQuestionRepository db = new QuestionRepository();
IQuestionsService service = new QuestionsService(db);

This means that The QuestionsController needs to reference IQuestionRepository, QuestionRepository, IQuestionsService, QuestionsService . And this is inevitable because somewhere the concrete class needs to be declared.

However, using Dependency Inversion and The Stairway Pattern we can simplify our code further.

The Stairway Pattern

Figure 2: The stairway pattern

We can implement it using stairway patter (so-called due to the looks of a stairway). Here we let each layer depend on the abstraction (interface) of the next layer and the behavior is then implemented through the actual class.

Each step also represents one unique layer. The diagram is modified to clarify where the original class could be instantiated, therefore each layer has a reference to both the interface class and the implementing class.

We begin with breaking out the code to different projects/folders. One project for the start point, in this case, the API. Then two projects per layer where one represents all the service interfaces and one for all service implementations, the same applies to the data layer.

For a project structure in C# we get the following folder structure (notice changes in bold):

Quiz
│   README.md
│   Quiz.sln
│
└───Quiz.Api
│       QuestionsController.cs
│       Startup.cs     
│   
└───Quiz.Service.Interfaces
│       IQuestionsService.cs
│   
└───Quiz.Services
│       QuestionsService.cs
│
└───Quiz.Data.Interfaces
│       IQuestionRepository.cs
│   
└───Quiz.Data
        QuestionRepository.cs

Instead of declaring an instance every time, we will use Dependency Injection to declare it once in our startup.cs which will be responsible for the concrete class.

// This method gets called by the runtime. Use this method to add services to the container.
 public void ConfigureServices(IServiceCollection services)
 {
     services.AddScoped<IQuestionsService, QuestionsService>();
     services.AddScoped<IQuestionRepository, QuestionRepository>();
     services.AddControllers();
 }

In this case, the API project still has a reference to all other projects because Startup.cs needs to import all the projects to be able to declare them for the dependency injection.

Moving the startup configuration to each project

We may move the responsibility to each layer by having a configuration file in each project. With a sequence of Startup.cs -> ServiceConfiguration.cs -> RepositoryConfiguration.cs we can remove references from the API project and let each project only refer to layers below. Observe the following structure:

Quiz
│   README.md
│   Quiz.sln
│
└───Quiz.Api
│       QuestionsController.cs
│       Startup.cs     
│   
└───Quiz.Service.Interfaces
│       IQuestionsService.cs
│  
└───Quiz.Services
│       QuestionsService.cs
│       ServiceConfiguration.cs 
│
└───Quiz.Data.Interfaces
│       IQuestionRepository.cs
│   
└───Quiz.Data
        QuestionRepository.cs
        DataConfiguration.cs

This is how the startup configuration will look like for each project:

API project — Startup.cs with a reference to Quiz.Services & Quiz.Service.Interfaces projects.

//Startup.cs
 public void ConfigureServices(IServiceCollection services)
 {
    services.AddServiceDependencies(Configuration);
    services.AddScoped<IQuestionsService, QuestionsService>();
    services.AddControllers();
 }

Service project — ServiceDependencies.cs with a reference to Quiz.Repositories& Quiz.Repository.Interfaces

//ServiceDependencies.cs
public static IServiceCollection AddServicesDependencies(this IServiceCollection services, IConfiguration configuration)
{
    services.AddRepositoryDependencies(configuration);
    services.AddScoped<IQuestionRepository, QuestionRepository>();
    return services;
}

Data project — Last layer, so no more dependencies, however, a configuration, for example, a database can be needed from an external dependency, therefore, we need a configuration file to represent these injections. Here we use MySql with the connection string passed from appsettings.json.

//appsettings.json
{
  “Logging”: {
  “LogLevel”: {
  “Default”: “Information”,
  “Microsoft”: “Warning”,
  “Microsoft.Hosting.Lifetime”: “Information”
 }
 },
   “AllowedHosts”: “*”,
   “ConnectionStrings”: {
   “Database”: “Server = db;
                port = 3306;
                database = quiz_db;
                user = quiz_user;
                password = quiz_password;
                Persist Security Info = false;
                Connect Timeout = 300”
 }
}
//RepositoryDependencies.cs
public static IServiceCollection AddMyClasses(this IServiceCollection services, IConfiguration configuration)
{
    services.AddDbContext<QuizContext>(
    options =>
    {
        string V = configuration.GetConnectionString("Database");
        options.UseMySql(V, ServerVersion.AutoDetect(V));
    });
     return services;
}

What if we want to have a DTO (Data Transfer Object) that is being shared from the repository to the API?

Objects that are common or shared across different layers can be packed in a separate project. This way, changes to DTO are only done in one place to avoid circular dependencies by not allowing the common project to have bi-directional dependencies. Hence, the layers may refer to the common project but not the other way around, notice the blue dotted lines in figure 3.

Figure 3: Dependencies in Stairway Pattern with a common project

Discussion

Cleaner Code

It gets easier to work with the code by being able to choose one layer to look into and handling one responsibility one layer at a time. The dependency configuration with dependency injection and dependency inversion simplifies future replacements in the layers. E.g., to change the repository implementation, you create a new concrete class that implements the interface and change one row in the service configuration to make sure it uses the new implementation.

// OLD repository
// services.AddScoped<IQuestionRepository, QuestionRepository>();
// new Improved repository
services.AddScoped<IQuestionRepository,
                   ImprovedQuestionRepository>();

Unit Testing

Think of mock testing, imagine you want to test a single API call that calls a service class and also does a database call. Testing would require a mock of the service and the database. However, if we split them up into layers, the API only references the service layer, hence, only the service layer needs to be mocked for testing the API. The same is applied when testing services, only the database layer needs to be mocked.

Pros

+ Code readability.
+ No Cirucular Dependencies
+ Easier to write unit tests
+ Single responsibility

Cons

- May make deployment more difficult since you have multiple projects instead of a single one.

Conclusion

So what do we gain from this? We get an improved code structure as well with no circular dependencies. It is also easier to get an overview of the code since you now both have the responsibilities divided into layers and interfaces. It gets easier to replace concrete code implementations with new ones by simply editing the start-up configurations. Also, it is easier to write Unit tests for each layer since each layer only requires one layer of dependency to test the specific layer.

Source Code

The source code can be found @ GitHub