Thanks a lot! I remember commenting on a previous Dependency Injection vid of yours that I felt this last step on Runtime was always missing on videos introducing the subject, and not just yours but in general. So really nice to see you follow it up :)
This is amazing, thank you. I have a use case right now where I have different ERP backend systems depending on the customer setup and now I can abstract it even more.
Please, no. Here, you are using the service locator pattern. Meaning that if you ever want to unit test this kind of code, you will have to setup a test double for the locator itself, and your tests will be tied to implementation details.
We used keyed services in a real-world application where we have different implementations for controller actions and for background services (since the latter don't have a HttpContext we needed).
Patrick, it's time to embrace the new C# features. For starters, add a semicolon after namespaces to eliminate unnecessary indentation and clean up your code. You're missing out on many great updates!
Thanks for showing it. It is reallllly fucked up unfortunately. It is cute in demos like this but once the colleagues will start using it in a huge business app, I won't be happy as a reviewer. Who the hell will track down the string! keys if they exists (without typos) or not? I know.. write tests for it.... Another thing which is easily avoidable if you just simply don't want to do such a thing with DI!
Agreed, this problem can be solved by registering multiple implementations and then looping through them (a simple linq .single call) to get the specific one you need. Usually used alongside the strategy pattern.
Two months ago you posted a video "Dependency Injection Has Limits: Enter the Factory Pattern", is this video only valid now with .NET 9.0? l Seems like even the Factory Pattern relies on Dependecy Injection. Either I'm confused or I was click baited :c
I never got the point of keyed services. The point of DI is inversion-of-control, and providing the key on the receiving end to choose the dependency somewhat reverts that inversion. In my opinion, this turns DI into the infamous service locator (anti)pattern - as does injecting the IServiceProvider.
I know that when you resolve a service from IServiceProvider, it will not be disposed when the request's scope is over, causing memory leak. Am I right?
I am more worried about the use of primary constructors. primary constructor behave different from 'normal' constructors. The service provider is maybe less clean, but it works the same.
generally yes but also no. this depends on where and why you gonna do it. if using injection is possible go for it, but sometimes in program.cs you gotta retrieve services to build your app so you use service locator pattern.. or in this situation.
@@yamenassaf3564 that's "captive dependency". basically you shouldn't inject a service that has shorter lifetime than the service being injected to. so you should first create a scope and then resolve service using that scope, that has a "using" keyword for proper disposal. however, a very bad way to resolve services is by first using "BuildServiceProvider", don't ever do that. btw regarding memory leak, i would worry more for the changed behavior of the app.
Are you referring to DI it self or the place where DI is done? If it's just the place. Do it somewhere else. This is just a quick video. If it's about DI it self... then you don't understand DI and I recommend doing some research on it.
This is just an example. You don't have to register them there. For example you could create a static class and register them there using an extension method.
@@mynameisshadywhat But I guess you still have to do it before building the webhost. So it still does not solve problems like plugins for webapps without restart and stuff like that...
Thanks a lot!
I remember commenting on a previous Dependency Injection vid of yours that I felt this last step on Runtime was always missing on videos introducing the subject, and not just yours but in general.
So really nice to see you follow it up :)
This is amazing, thank you. I have a use case right now where I have different ERP backend systems depending on the customer setup and now I can abstract it even more.
Please, no. Here, you are using the service locator pattern. Meaning that if you ever want to unit test this kind of code, you will have to setup a test double for the locator itself, and your tests will be tied to implementation details.
Thank you, it is very easy to understand your explanations. Here take one extra sub ♥️♥️
Thanks Patrick for the video.
I hope you talk about Lazy Injection and when we use it and it's Pros and Cons
What a wonder video...Thank you so much...:)
We used keyed services in a real-world application where we have different implementations for controller actions and for background services (since the latter don't have a HttpContext we needed).
Patrick, it's time to embrace the new C# features. For starters, add a semicolon after namespaces to eliminate unnecessary indentation and clean up your code. You're missing out on many great updates!
You sound like you would be the kind of person to complain about the type of earrings your hooker is wearing
Thanks for showing it. It is reallllly fucked up unfortunately. It is cute in demos like this but once the colleagues will start using it in a huge business app, I won't be happy as a reviewer.
Who the hell will track down the string! keys if they exists (without typos) or not? I know.. write tests for it.... Another thing which is easily avoidable if you just simply don't want to do such a thing with DI!
Agreed, this problem can be solved by registering multiple implementations and then looping through them (a simple linq .single call) to get the specific one you need. Usually used alongside the strategy pattern.
Don't use magic strings. Declare valid keys as constants in a class.
@@krccmsitp2884 afaik the key could be anything so why not make it typeof(foo)?
Congratulation, you just destroyed the entire Unit Testing 😐
It already works in .NET 8.
Helpful
Two months ago you posted a video "Dependency Injection Has Limits: Enter the Factory Pattern", is this video only valid now with .NET 9.0? l
Seems like even the Factory Pattern relies on Dependecy Injection. Either I'm confused or I was click baited :c
These kind of videos show and explain options, but the decision is always up to YOU when to use what. Same as with design patterns.
I never got the point of keyed services. The point of DI is inversion-of-control, and providing the key on the receiving end to choose the dependency somewhat reverts that inversion. In my opinion, this turns DI into the infamous service locator (anti)pattern - as does injecting the IServiceProvider.
it just mapping , i dont like it the new trend and newbies confuse .
I‘m not a great fan of keyed services and the benefit of it. Why not use for every ManaSerivce a specific interface that inherits from IPotion?
Isn't using service provider anti-pattern?
Good video though. Short and sweet 😊
I know that when you resolve a service from IServiceProvider, it will not be disposed when the request's scope is over, causing memory leak.
Am I right?
I am more worried about the use of primary constructors. primary constructor behave different from 'normal' constructors. The service provider is maybe less clean, but it works the same.
generally yes but also no. this depends on where and why you gonna do it. if using injection is possible go for it, but sometimes in program.cs you gotta retrieve services to build your app so you use service locator pattern.. or in this situation.
@@Forshen you can always assign them to a private read-only field.
@@yamenassaf3564 that's "captive dependency". basically you shouldn't inject a service that has shorter lifetime than the service being injected to. so you should first create a scope and then resolve service using that scope, that has a "using" keyword for proper disposal.
however, a very bad way to resolve services is by first using "BuildServiceProvider", don't ever do that.
btw regarding memory leak, i would worry more for the changed behavior of the app.
Interesting, but having to register all those in program.cs isn't great.
So register them somewhere else. This is just sample code.
Are you referring to DI it self or the place where DI is done? If it's just the place. Do it somewhere else. This is just a quick video. If it's about DI it self... then you don't understand DI and I recommend doing some research on it.
This is just an example. You don't have to register them there. For example you could create a static class and register them there using an extension method.
@@mynameisshadywhat But I guess you still have to do it before building the webhost. So it still does not solve problems like plugins for webapps without restart and stuff like that...
why would we ever need it
IoC (solid i principle) - inversion of control