Made EASY - WPF Dependency Injection with IServiceCollection

most modern applications are using some type of dependency injection framework that means if you're building WPF applications that's no different but what dependency injection framework should you be using for WPF hi my name is Nick centino and I'm a principal software engineering manager at Microsoft traditionally I've used autofac for almost all of my dependency injection however if you've used asp.net core and you're familiar with I service collection you're well aware that I service collection is a pretty robust dependency injection framework at this point in time so that means if you're building WPF applications you can probably do a whole lot using I service collection as your di framework so in this video I'm going to walk through how we can set that up with a very simple example and we can see how we can start to do dependency injection and get our services resolved to go start our WPF application a quick reminder that if you like this kind of content subscribe to the channel check out that pin comment for my courses on dome train and let's jump over to visual studio and our WPF app on my screen I have a simple w WPF application this is from a previous video that I have done so if you haven't checked that out you're not familiar with WPF you should go check out that video there'll be a link above you can go check it out come back but it's really just a super quick primer on some things in WPF if you're not familiar with the framework at all to start things off and where I was leaving off in that video is that some of the patterns in WPF I'm not a huge fan of and one of them is that when we're dealing with data contexts which are sort of like the thing that we want to be able to bind to like the code behind the state that we want to bind to with our control a lot of the times we end up doing things like newing them up in the constructors or from the outside of the class we've made a new instance of main window and someone else on the outside will go assign the data context I'm not a huge fan of either of those two things and that's because I much prefer to have things passed in through the Constructor traditionally what I would like to see is something like this main window view model gets passed in here so we'd have a view model here and then we go do something like this this totally works it's functionally going to be identical as long as we go instantiate a new one of those things before we create the main window but what we find a lot of the time is that in WPF we're not creating things like this in my experience it almost feels like an anti- pattern that you're working against things because the way that we're creating a lot of these controls really is that we have a parameterless Constructor we'll go assign the data context blah blah blah just not what I like to do and doesn't mean that it's right or wrong it's just a personal preference and I find that it's not very common I see WPF code written like this I almost wish that this was enforced and that way a lot of dependency injection Concepts just kind of apply naturally this is going to be one of the first steps that we can take to go make dependency injection work pretty smoothly when we're dealing with a simple window like this so in this example application what I'm going to do is basically transform it into using dependency injection instead of what we normally see this is just a brief Interruption to remind you that I do have courses available on dome train focused on C so whether you're interested in getting started in C looking for a little bit more of an intermediate course focus on objectoriented programming and some async programming or are you just looking to update your refactoring skills and see some examples that we can walk through together you can go ahead and check them out by visiting the links in the description and the comment below thanks and back to the video if I were to go run this now this is not going to do what we want and I'm going to back it up a little bit so you can see the difference when I go run it but when I go create the data context like this if I go show you in the zaml we are binding the window title to custom title and there's a label right in the middle of the screen that we're binding to custom label if I jump back into the code you can see those two values defined here so if I go run this now right there's no dependency injection or anything fancy going on but we do have that binding working as we might expect very simple but if I go back and put this code in I had to go use dependency injection what's going to happen we're going to get an exception thrown and that's because we're unable to go find as it says here the right Constructor why is this happening how did we go build this main window in the first place why can't it know what the view model is what's up right so it's just another quick example of why you don't see this thing really as a first class approach for going to do this kind of stuff but that's okay there's going to be something we can easily do to change this up the first thing to understand is how is main window actually getting instantiated I don't know where that is in the code if we go look here right this is the startup part of the application there's nothing that even says go make a new main window and show it that's because it's happening on app xaml.cs you can see this startup Ur points at the main window zaml file WPF knows to go launch this window as the startup and in fact if I go take this off completely which is going to seem kind of funny this application is going to air quotes work it's going to work but not do anything at all you probably can't tell but this application is currently running it's doing exactly what we said you can see in Visual Studio there's a stop button and I can't continue because it is currently running it's just not showing a window because we didn't tell it to we got to play around these two concepts the first is that if we have this code in here to have this startup URI it's going to try looking for a public parameterless Constructor on Main window the problem is that we don't have that and we don't have that because I've gone ahead and I've modified the only Constructor to take in the view model I want to force us to pass this thing in because I don't think we should have a main window without providing the view model for it this is a design philosophy that I like to have when I'm building with UI Frameworks and in fact with most applications I like to be able to pass stuff in through the Constructor not assign it afterwards okay so what are what are we going to do about this and this is where dependency injection is going to come into play we are going to keep this part removed we don't want to have our application launch the window that way instead we're going to take control of the startup of our application we're going to set up a dependency injection container and then we're going to resolve the main window to make sure that we can show it and the final thing if you stay to the end of this video is I'm going to show you how you can make this a plugin which is pretty cool in my opinion in order to make this work I'm going to start leveraging I service collection to make sure that we can get dependency injection set up so we're going to do that inside of the Constructor of our application so we're going to go public app to get the Constructor going on here and then from there what I'd like to do is create the service collection so we'll have a service collection so this is going to come from the Microsoft extensions dependency injection so if you're not familiar with that if you're used to uh ASP onet core you're getting that automatically but it is this nougat package right here that I've added in from there we go take our service collection we'll make a new one then we need to go register our services so traditionally what you see is either what co- pilot suggesting here with this kind of syntax or you will see that people end up using extension methods and kind of flip the order of these things to read how they'd like we'll come to that in just a moment what I'm going to do now is make the service provider so thank you very much co-pilot for doing that for us then what we're going to do is resolve the main window and you can see co-pilot knows what's up up so we'll get that main window and then main window. show which is also what co-pilot knows how to do but the problem right now is that we have not gone and done this so I'm just going to show you how this works the traditional way it's again very common thing that you'll see in ASP onet core I don't have to do any work just blab apparently and co-pilot can do the rest this is the future of software engineering if you're curious there we go we have our extension methods you can see that we're adding Singletons in for the view model and the main window again if we go back up here and think about what this is doing we're going to make our container so our service collection we will do the configuration which registers these two things down here these are two dependencies we need we'll get the service provider so we'll finish sort of building that container then we go resolve our main window now by doing this if you recall when I ran the application before it crashed it basically said hey look I know you're asking for the main window but I can't build this thing because I don't even know where this main window view model ising from with dependency injection especially the way we've set this up we're able to get that automatically so if we go ahead and press play we should see that this resolves our dependencies very nicely for us we get the view model inserted into the window automatically through the Constructor and then all the bindings take place perfectly for us as we can see on the screen right now now I did mention that if you stay towards the end of this video I will show you how to make this work with plugins and that's exactly what I'm going to show you in this next video that you can watch here thanks and I'll see you next time