Structuring Dependency Injection In ASP.NET Core The Right Way

Dependency injection is one of the best features that ASP.NET Core introduced. With transient, scoped and singleton service lifetimes, there are many concepts to grasp. So it's easy to lose sight of the dependency injection configuration code. In this video, I'll show you two ways to organize your dependency injection configuration with maintainability in mind.

Join my weekly .NET newsletter:

Read my Blog here:

Subscribe for more:

Chapters
0:00 The problem with the Services configuration
0:57 Extension methods for Services configuration
8:21 Potential issue with the extension methods approach
9:15 IServiceInstaller for Services configuration

[peleacezar]

The second approach is very elegant and at the same time a less common way to inject your dependencies into the project. Congratulations for another extremely useful material 😃

[MohammadZare]

Great approach. I think it's good to add an order property to specify which dependency should be injected first...

[this-is-bioman]

I used to be a fan of reflection mechanics liked this until I had to reverse engineer my own code several months later so now I think the explicit nature of the extension approach is going to cause you much less headaches in future.

[montanomariano]

I've been using the extension method approach for some time now. It's very clean. The Automatic installer is a very interesting approach too. I saw something very similar a while back, just before .NET Core dependency injection system, in a great instructor's channel from whom I learned a lot (Tim Corey) with Autofac Nuget Package.

[Rob_III]

@0:40 "You can see we have close to 100 lines of code to configure our services". @8:10 Now we have 130 lines of code in another file. I would've gone one step further and put unrelated stuff (essentially each extension method in this example) in it's own separate file.

Other than that: nice video, keep up the great work! I enjoy your videos very much!

[pw.]

I really like the reflection method you've used there. The fact that you can use that straight out of the box like that, just by implementing an interface... Excellent. I did have a bug, but that was down to me being stoopid. Top job, chap.

Thanks for the video
when you use Extension methode, you can avoid returning IServiceCollection no need

[Swzvtlbngfd]

Very helpful in understanding how to organize ever growing dependencies

[vikasjoshi]

Thanks for introducing super compact and maintainable way of doing better DI @Milan

[dcuccia]

Nice summary. And a good reminder that I don't need Scrutor for simple tasks like this. One thought - with C#'s static virtual members in interfaces, we can avoid that extra step to instantiate IServiceInstaller objects, just to call a method (which can now be static).

[stef]

Awesome! Exactly what I was looking for. Thank you Milan.

[mrsajjad]

Great lesson. Thank you for sharing these gems for free.

[emwagner]

You're a programming genius, Milan!

[MrFunkyCabbage]

YOu actually touched on some good points here, especially when it came to the service installers side of things... Super video! thanks.

[Isrd]

The second approach is more like a modular design. if you need to go this route, you may need to implement an int property into your `Installer` interface, to be used for ordering the executions of the installer (e.g. SortOrder, . priority, etc..). This can be also extendable if you are into a modular systems ;).

[nage]

Love aproach with reflection, doing like that for a some time already )

[tonycaesar]

I'm torn between the two options. I have tend toward the first extension strategy in the past. I like the idea of having a different file for each startup type regardless of the strategy. It keeps the code better organized and easier to find startup elements. The reflection approach has a certain sense of magic while still being clean and easy to maintain. Magic for me is bad because it detaches you from what is happening and can be harder to maintain. One catch to the reflection startegy is I may want to selectively switch between different startup extensions to cover different scenarios (mock, test environment, etc.). The reflection strategy makes that a little more difficult but not impossible. Which do you find yourself using more and why?

[rhlee]

Hi Milan, great video. You may use SHIFT ALT and . (dot) to select next occurrence, so you don't have to manually select and paste.

[shakib]

I think a nice way to reduce dependency registrations, is using Interface marking, but not with tools like scrutor. because it will make application start up slow and heavy (because of reflection stuff). Instead we can create a source generator to wisely check the interface marks and inject them using a partial method.

[paikesitics]

Nice! I'll apply your approach. Thanks.