IoC and messy factory methods
Hi... so I've made a class library that uses IoC - i.e. ServiceCollectionExtensions and registering all the dependencies.
In the library I have SomeClass that has 3 dependencies injected in the constructor. Those dependencies also themselves have dependencies, and so on, such that initializing SomeClass without an IoC container becomes messy... Now I need to consume SomeClass from a project that doesn't use IoC. It would be too much work to be able to use the IoC in my new project. What's the general approach for this type of thing?? How can I support an IoC container but also not have to make horrendous factory methods for classes in my class library so that I can consume them without an IoC container...
19 Replies
use a service collection in your factory method
You know you can
new ServiceCollection()
and then add to it, right? And then do .BuildProvider()
It's not like it's something you can't use standaloneThanks, yeah I thought that might be the best way to go about it...
Some notes on the theory here:
Constructing an object graph manually by instantiating the object and all its dependencies via their constructor is called "Pure Dependency Injection".
The DI container can automate that task via a process called "Auto Wiring", which is how it figures out which dependencies to inject into requested object graphs (services).
You're facing the usual trouble with pure DI, which is that anything past a trivial object graph becomes a hassle to create.
So as Anton advised, you should switch to an automated solution via auto wiring, which the DI container
IServiceProvider
does for you.I guess my concern is that I have to actually introduce an implementation of an ioc container rather than just using the abstractions
I don't know what you mean by that.
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
yeah but it is in the standard library iirc
Nope!
ServiceCollection
is published as part of the NuGet package Microsoft.Extensions.DependencyInjection.Abstractions
, you probably do not want to have that reference directly in your core/library, so I think your best bet would be to create a seperate CSPROJ (if possible) that gives you an instance (of SomeClass
) utilizing the nuget package. That project can then be consumed from the app that has no IoC container.Mmm I don't know about that - what's the issue with refrencing the Abstractions nupkg
As of now you should be only having a reference to IServiceCollection in your library, to register the services (AddSingleton/Scoped/Transient).
When you are building the ServiceCollection yourself (in the same library) you lock in on the DI provider.
That is not really a bad thing, usually the Microsoft IoC Container is sufficient.
Other IoC Frameworks (like AutoFac) work by providing an adapter from IServiceCollection to their way of registering services.
That means having the hard reference to the ServiceCollection is not really required in your library, because you are working on IServiceCollection.
However, if I am not mistaken, it seems that these extension methods anyway come from said
Microsoft.Extensions.DependencyInjection.Abstractions
package.. so you would not even add an additional nuget reference to your library if you are not splitting. In my memory ServiceCollection (the class) and the extension methods (on IServiceCollection) were in seperated NuGet packages.
Hope that makes sense. :)IUnknown User•2d ago
Message Not Public
Sign In & Join Server To View
I actually thought that the abstractions were applicable to all containers, but I could be wrong. That is to say that if I have a servicecollectionextensions class using Dependency.Abstractions, I could consume that with an autofac container - but I could be wrong!
just .net fw unfortunately
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
As long as your extension methods use IServiceCollection to register your services you are good to go.
yes, .net framework 4.8 to be exact
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
Haha , ask anyway! I also work in net core in other projects
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View