I usually create file called ServiceCollectionExtensions.cs and than add extension method over IServiceCollection to register module. Usually, if project register something it has Add<ModuleName> method. For me it works. Do you see other benefits of using AutoFac instead of built-in DI?
I am a Software Engineer loving to collaborate with Ops to tear down silos and improve software quality. Founder of zyrrio.
Communication and collaboration are the skills I value most.
Usually I add different dependencies based on the feature I am working. So I split up my applications in multiple namespaces in the project. Each namespace being a well-defined set of features (or bounded context in DDD terms).
Each of these namespaces has its own module, which defines the dependencies it requires as part of the Module.
I think, when reading the code its easier to find the configurations and dependencies easier.
Do you see other benefits of using AutoFac instead of built-in DI?
I am used to it and it is a very good DI container in my point of view. It has some advanced features (but they rarely should be used).
Compared to the ASP.NET DI, I like the AssemblyScanning features, that allow to register all types implementing an interface or something like that.
As for the practices described in this blog: If you are happy with the ASP.NET DI I would suggest you keep using it. If you are already using Autofac, here you have a way to improve modularity of the ASP.NET registrations
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I usually create file called
ServiceCollectionExtensions.csand than add extension method overIServiceCollectionto register module. Usually, if project register something it hasAdd<ModuleName>method. For me it works. Do you see other benefits of using AutoFac instead of built-in DI?Usually I add different dependencies based on the feature I am working. So I split up my applications in multiple namespaces in the project. Each namespace being a well-defined set of features (or bounded context in DDD terms).
Each of these namespaces has its own module, which defines the dependencies it requires as part of the Module.
I think, when reading the code its easier to find the configurations and dependencies easier.
I am used to it and it is a very good DI container in my point of view. It has some advanced features (but they rarely should be used).
Compared to the ASP.NET DI, I like the AssemblyScanning features, that allow to register all types implementing an interface or something like that.
As for the practices described in this blog: If you are happy with the ASP.NET DI I would suggest you keep using it. If you are already using Autofac, here you have a way to improve modularity of the ASP.NET registrations