3 layer architecture In DI based software

Question

I'm building software with 3 layer architecture and asp.net core , as you know the Dependency Injection is Built Into Asp.net core

As i know the 3 layer architecture diagram is like this:

According to above diagram we don't have any direct connection between Data Access layer and UI layer

My project is:

My question is if we don't have direct connection between UI And Dal how we can register our DAL as service in UI layer?

Answer 1

The entry point of the application (the UI project) must setup the DI container, providing implementations of all the dependencies. That's why it must have direct connection (reference) to all the other projects.

What is important is that the UI classes have dependencies only on BLL classes. The additional references are only for setting up DI.

Answer 2

First point - For simplicity, the answer by Rumen is correct.

What I do in larger solutions is to have a separate Infrastructure project which set's up the dependency injection container (in .net core, this would be the IServiceCollection).

For example in my current solution I have both a Website & an API. Both of these call methods in my Infrastructure project to setup the dependency injection. In my UI projects I can then decide which dependencies I want to setup without needing to know the code. e.g.

• For testing, I can use an extension method called "AddMockRepositories" e.g. "_serviceCollection.AddMockRepositories()"
• For Development, I can use "AddRepositories(connectionString)
• For Production, I can use "AddCachedRepositories(connectionString, objectCache)

There are 2 advantages to this approach:

1. All of the DI code is in one project - We get to share this between other projects without duplicating any of the code. This includes being able to share the caching code which is extremely useful.
2. The UI projects do not have to reference the DAL. This means no one can directly reference the DAL from the UI project, accidentally or not.

As a side note, I'm not sure how well this translates for other DI frameworks. I imagine they all set up dependencies similarly but I have only done the above using native .net core dependency injection.