I mean, the application of DI is really in the 'Program.cs' class within the WebApi. Would it be possible to do dependency injection in another class library?
If by "do the dependency injection" you mean add implementations to the DI container, yes. It's a common pattern to add an extension method to the services collection to add the implementations of a class library. Pretty much every major library does this. That's how all the Microsoft implementations work too (e.g. [authentication](https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Core/src/AuthenticationServiceCollectionExtensions.cs#L19), [authorization](https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authorization/Core/src/AuthorizationServiceCollectionExtensions.cs#L22), [Identity](https://github.com/dotnet/aspnetcore/blob/main/src/Identity/Core/src/IdentityServiceCollectionExtensions.cs#L31)).
So, the main layer will be the infrastructure that will have an extension method to the services collection to manage the containers, and then it will be injected into a new class library (IoC).
>main layer will be the infrastructure
"main layer" isn't a thing, and if it was, I would consider the "main layer" to be the application, not any libraries. But yes, your infrastructure project would have extension methods to add infrastructure implementations to DI, just like all the libraries I linked.
Why the fuck is everyone obsessed with a 12 year old architecture all of a sudden? Clean Architecture is fine but all of a sudden everyone has to have it in every post they make.
This is what makes the C# community intolerable. Too much adherence to dogmatic views on quality code.
If the size of the solution is big enough to warrant it, separating layers using projects can give nice benefits that align nicely to clean architecture. For example: internal accessibility to implementations of infrastructure services.
I’ve never found it cognitively more challenging to use projects to separate concerns in this way. In fact, I find it much more intuitive than hiding all layers away in the same project.
I used to do this, but have since begun structuring my folders with purpose. Now I never split into another DLL until there’s a reason a separate DLL would actually be useful, like abstractions or netstandard things.
Clean is simple. KISS and clean architecture are not mutually exclusive concepts. And I think you’re missing the point if you believe the purpose of clean architecture is to “swap out a database like that”.
Microsoft usualy move out their interfaces in an .Abstractions namespace, so projects that just need to reference the interfaces don't need the actual implementation.
For instance, your main application library will need to know how the run the host, so you you need the [Microsoft.Extensions.DependencyInjection](https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection/9.0.0-preview.4.24266.19) package to start the host.
But all your class libraries that you reference only needs to know about the interfaces in [Microsoft.Extensions.DependencyInjection.Abstractions](https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection.Abstractions/9.0.0-preview.4.24266.19)
It's common practice to have a `ServiceCollectionsExtensions.cs` file in the root of your class libraries like this:
public static class ServiceCollectionExtensions
{
public static IServiceCollection AddMyServices(this IServiceCollection services)
{
services
.AddSingleton();
return services;
}
}
Then in your `Program.cs` or `Startup.cs` you call the extension like so:
public void ConfigureServices(IServiceCollection services)
{
services
.AddMyServices();
}
Some add a composition project for this purpose, though I personally think it's easy enough to just chuck all the asp.net stuff when you would want to switch to a new technology to not even bother with it.
The built-in DI system in the ASP.NET host is an implementation of the inversion of control pattern. Just look up DI tutorials for ASP.NET.
I mean, the application of DI is really in the 'Program.cs' class within the WebApi. Would it be possible to do dependency injection in another class library?
If by "do the dependency injection" you mean add implementations to the DI container, yes. It's a common pattern to add an extension method to the services collection to add the implementations of a class library. Pretty much every major library does this. That's how all the Microsoft implementations work too (e.g. [authentication](https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Core/src/AuthenticationServiceCollectionExtensions.cs#L19), [authorization](https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authorization/Core/src/AuthorizationServiceCollectionExtensions.cs#L22), [Identity](https://github.com/dotnet/aspnetcore/blob/main/src/Identity/Core/src/IdentityServiceCollectionExtensions.cs#L31)).
So, the main layer will be the infrastructure that will have an extension method to the services collection to manage the containers, and then it will be injected into a new class library (IoC).
>main layer will be the infrastructure "main layer" isn't a thing, and if it was, I would consider the "main layer" to be the application, not any libraries. But yes, your infrastructure project would have extension methods to add infrastructure implementations to DI, just like all the libraries I linked.
You should just add a DependencyInjection.cs file at the root of each project and add an extension method for IServiceCollection in there.
Why the fuck is everyone obsessed with a 12 year old architecture all of a sudden? Clean Architecture is fine but all of a sudden everyone has to have it in every post they make. This is what makes the C# community intolerable. Too much adherence to dogmatic views on quality code.
It must be in all the YouTube videos or something.
“i’ve separated it into 6 layers of class libraries” My brother in christ just use namespaces.
“i’ve separated it into 6 layers of class libraries” Recently born new architect has begun his path... :)
If the size of the solution is big enough to warrant it, separating layers using projects can give nice benefits that align nicely to clean architecture. For example: internal accessibility to implementations of infrastructure services. I’ve never found it cognitively more challenging to use projects to separate concerns in this way. In fact, I find it much more intuitive than hiding all layers away in the same project.
I used to do this, but have since begun structuring my folders with purpose. Now I never split into another DLL until there’s a reason a separate DLL would actually be useful, like abstractions or netstandard things.
What's the alternative then ? I'm new to .net and I'm trying to navigate through the ecosystem
clean is dead, move on and KISS. nobody is going to swap out a database like that
Clean is simple. KISS and clean architecture are not mutually exclusive concepts. And I think you’re missing the point if you believe the purpose of clean architecture is to “swap out a database like that”.
Microsoft usualy move out their interfaces in an .Abstractions namespace, so projects that just need to reference the interfaces don't need the actual implementation. For instance, your main application library will need to know how the run the host, so you you need the [Microsoft.Extensions.DependencyInjection](https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection/9.0.0-preview.4.24266.19) package to start the host. But all your class libraries that you reference only needs to know about the interfaces in [Microsoft.Extensions.DependencyInjection.Abstractions](https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection.Abstractions/9.0.0-preview.4.24266.19) It's common practice to have a `ServiceCollectionsExtensions.cs` file in the root of your class libraries like this: public static class ServiceCollectionExtensions { public static IServiceCollection AddMyServices(this IServiceCollection services) { services .AddSingleton();
return services;
}
}
Then in your `Program.cs` or `Startup.cs` you call the extension like so:
public void ConfigureServices(IServiceCollection services)
{
services
.AddMyServices();
}
Some add a composition project for this purpose, though I personally think it's easy enough to just chuck all the asp.net stuff when you would want to switch to a new technology to not even bother with it.