💡 Learn how to program in C#: - dometrain.com/course/getting-started-csharp?affcode=1115529_nl-teyzg 🧠Deep dive on C#: - dometrain.com/course/deep-dive-csharp?affcode=1115529_nl-teyzg 🎁Zero to Hero C# Bundle: - dometrain.com/bundle/from-zero-to-hero-csharp/?affcode=1115529_nl-teyzg 💪 Skill up your refactoring: - dometrain.com/course/from-zero-to-hero-refactoring-for-csharp-developers?affcode=1115529_nl-teyzg ✉ Subscribe to my free software engineering newsletter: - subscribe.devleader.ca
Curious how would you measure whether the dependency injection is working effectively for WPF? For example, one scenario can be that we are closing the main window, meaning not using data and services related to this window and I would like to free the data. But the app is still running. How can we free the unwanted memory and know DI is doing its work effectively?
@@vickyli66 this is a question of lifetime of objects - if you need objects to be coupled to the lifetime of another, so your dependencies only exist as long as you do, you don't want to use single instance behavior. If the dependencies are disposable, you can try putting a breakpoint in there to ensure it's getting called. But essentially you want to match dependency lifetime with the thing that uses them. Most of my "services" are either stateless (so this doesn't matter) or they're stateful but exist the entire duration of the app -- so it avoids this a lot. Sometimes I'll make dedicated factory pattern objects so I can EXPLICITLY control lifetime just so it feels more obvious.
I really appreciate your content on WPF. I feel that it gets passed over for browser-focused tutorials but is really good skill to know more about. Thanks!
@@DevLeader I'm just learning WPF and find it to be a great framework, and it's nice to build native apps instead of web apps. Thanks for your help and content.
I'll need to do a follow up video on this. You won't be able to make that work unless you can register the converter onto your container though. If you *can* do that, it should be fine. In this context, you mean a value converter, right? Something you might use for binding?
@@DevLeader Correct, I just mean value converter. I would like to put logic into service which is commonly being unit tested, then invoke the service from value converter. It`s not easy to get service in value converter, or the value converter is in a sub project.
@@williamliu8985 let me add this one to the list - will try to get a video out. Should be very doable but the thing is we're probably fighting WPF here. If you put your binding with converter into XAML, then you don't own the lifetime creation of the converter via dependency injection. So we need to work around that 🙂
@@DevLeaderyeah that probably requires some tricks, one of them, we would require some static IServiceProvider in the Value converter class to resolve dependencies not via constructor
@@trebiax7960 yup - probably a few options but none I'm in love with. I've used them all before though: - You bite the bullet and slap a static property for doing service location onto your converter. This is the easiest and also least flexible especially when you get into testing. - We bypass XAML and wire these things up after resolving via constructor dependency injection (or similar). Way nicer IMO but you're immediately fighting against how this stuff was designed to be used lol
💡 Learn how to program in C#:
- dometrain.com/course/getting-started-csharp?affcode=1115529_nl-teyzg
🧠Deep dive on C#:
- dometrain.com/course/deep-dive-csharp?affcode=1115529_nl-teyzg
🎁Zero to Hero C# Bundle:
- dometrain.com/bundle/from-zero-to-hero-csharp/?affcode=1115529_nl-teyzg
💪 Skill up your refactoring:
- dometrain.com/course/from-zero-to-hero-refactoring-for-csharp-developers?affcode=1115529_nl-teyzg
✉ Subscribe to my free software engineering newsletter:
- subscribe.devleader.ca
Great stuff
Curious how would you measure whether the dependency injection is working effectively for WPF? For example, one scenario can be that we are closing the main window, meaning not using data and services related to this window and I would like to free the data. But the app is still running. How can we free the unwanted memory and know DI is doing its work effectively?
@@vickyli66 this is a question of lifetime of objects - if you need objects to be coupled to the lifetime of another, so your dependencies only exist as long as you do, you don't want to use single instance behavior.
If the dependencies are disposable, you can try putting a breakpoint in there to ensure it's getting called. But essentially you want to match dependency lifetime with the thing that uses them.
Most of my "services" are either stateless (so this doesn't matter) or they're stateful but exist the entire duration of the app -- so it avoids this a lot.
Sometimes I'll make dedicated factory pattern objects so I can EXPLICITLY control lifetime just so it feels more obvious.
I really appreciate your content on WPF. I feel that it gets passed over for browser-focused tutorials but is really good skill to know more about. Thanks!
I'll be covering more on it 🙂 I spent so long working with it and wish I would have made more videos over the last decade lol
@@DevLeader I'm just learning WPF and find it to be a great framework, and it's nice to build native apps instead of web apps. Thanks for your help and content.
hi there, how can I inject a service in usercontrol, thanks for answering
I try to cover that in an earlier video 🙂
ua-cam.com/video/AoQnI5St1Qg/v-deo.html
Hi Nick, how do you get service from IOC in converter. A step further, if the converter is from a sub project.
I'll need to do a follow up video on this. You won't be able to make that work unless you can register the converter onto your container though. If you *can* do that, it should be fine.
In this context, you mean a value converter, right? Something you might use for binding?
@@DevLeader Correct, I just mean value converter. I would like to put logic into service which is commonly being unit tested, then invoke the service from value converter. It`s not easy to get service in value converter, or the value converter is in a sub project.
@@williamliu8985 let me add this one to the list - will try to get a video out. Should be very doable but the thing is we're probably fighting WPF here. If you put your binding with converter into XAML, then you don't own the lifetime creation of the converter via dependency injection. So we need to work around that 🙂
@@DevLeaderyeah that probably requires some tricks, one of them, we would require some static IServiceProvider in the Value converter class to resolve dependencies not via constructor
@@trebiax7960 yup - probably a few options but none I'm in love with. I've used them all before though:
- You bite the bullet and slap a static property for doing service location onto your converter. This is the easiest and also least flexible especially when you get into testing.
- We bypass XAML and wire these things up after resolving via constructor dependency injection (or similar). Way nicer IMO but you're immediately fighting against how this stuff was designed to be used lol