DEV Community

.NET Core Dependency Injection: Everything You Ought To Know

James Hickey on December 10, 2018

If you go to the official docs for ASP.NET Core you'll find that Dependency Injection is under the "fundamentals" area. Is that true - is it reall...

Read full post

James Turner • Dec 11 '18

Great article! I've dealt with DI in .Net Framework via Autofac and while I like the new MS DI solution, I'm not 100% sold though that mostly comes down to what I'm use to rather than any inherent issue.

One of the first things I miss is from MS DI is being able to register all types (ie. AnyConcreteTypeNotAlreadyRegisteredSource in Autofac) and just manually specify types where I need config options or to a specific interface. There is probably a dozen reasons why I shouldn't do this which may be why it isn't easily available. That said, I did find a NuGet package today which provides simple assembly scanning for registering types.

The other thing was the naming of the DI functions: Transient, Scoped and Singleton (OK, well less this one). The amount of times I have needed to double check what one I am wanting is crazy though again, that is probably my own fault for not being very familiar with it yet.

Your tip for library authors is very useful too. In my library MongoFramework, I was planning to go down that path as my own research showed me that is how EF Core works. I ultimately didn't go down that road in the end but I might re-evaluate it in the future.

James Hickey • Dec 11 '18

Thanks for the kind word!

I agree that the DI system isn't as sophisticated as other solutions, but it's good to .NET Core allows devs to use another DI system easily if wanted. 👍

Timothy McGrath • Sep 1 '19

So, in your example, you have a Car that takes a HondaEngine, but in real life it doesn't really make sense to bind IEngine to HondaEngine. The whole point is that I might want to pass in a FordEngine or a ToyotaEngine.

So, now what?

I suspect I need to create an EngineFactory that I need to inject and then have it create the correct engine type outside the ctor. Is that right or is there a better way to do this?

James Hickey • Sep 3 '19

in real life it doesn't really make sense to bind IEngine to HondaEngine

Well, in some cases it might make sense. If you were, for example, building a multi-tenant / white-label app for the automotive industry (which I've done before) it might make sense to bind a concrete implementation of IEngine at app startup.

But yes, in other cases, when using late binding, then a factory could work.

You could also use the strategy pattern in conjunction with the DI container.

👍

Timothy McGrath • Sep 3 '19

That strategy pattern code is interesting. I had no idea you could do this:

services.AddScoped<IMathOperator, AddOperator>();
services.AddScoped<IMathOperator, SubtractOperator>();
services.AddScoped<IMathOperator, MultipleOperator>();
services.AddScoped<IMathOperator, DivideOperator>();

James Hickey • Sep 3 '19

It's pretty neat! As long as your interface exposes some way to differentiate between each concrete implementation then you can just check that at run-time.

Jonathan Higgs • Dec 10 '18

Is this ServiceProvider something they have added directly to .Net Core, or is it AspNetCore only?

James Hickey • Dec 10 '18

Yes, the ServiceProvider / DI system is baked right into .NET Core.

I wrote an article about task scheduling in a .NET Core console app - if you're interested to see what DI in a console application might look like (which would be in the ConfigureServices method when using the HostBuilder.)