FREELessons: 10Length: 1.5 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

5.1 Dependency Injection

ASP.NET Core has built-in dependency injection. In this lesson, we'll use the DI service to decouple our GuitarController and StaticGuitarRepository.

5.1 Dependency Injection

We've learned many things over the years, and one of those is that we don't want to use hard dependencies within our code. Well what do I mean by that? Well if we look at our guitars controller, we are using the static guitar repository as our guitar repository. Well we are being explicit as to the type of guitar repository that we're using, and we are creating that object here directly within the controller. This is a hard dependency. We have hard coded this. And ideally we wouldn't want to do this, because we don't always want to use a static guitar repository. That's great for testing and for development but in a production environment, we want to use a guitar repository that's interfacing with a real database. So we could write another guitar repository. And we could change the reference inside of the guitars controller but that doesn't give us really anything. Because we are still depending directly upon the code that we have hard coded here. And so for every environment we're going to have to change our code, recompile, and that's just a pain. So instead it would be nice if our guitars controller didn't care about the type of repository as long as it implemented the IGuitarRepository interface. So then, we could have a constructor that would accept an IGuitarRepository. And then we would set our _repo equal to the repository passed to the constructor. And that would be perfect because then any time that we created a guitars controller, we could pass in the repository based upon what environment we are in. And then everything is just going to work fine. The problem here is that is now the NVC framework can't create a guitars controller because it doesn't have a repository to pass to the constructor. The in NVC framework uses the default constructor to create our controllers and that is a constructor that has no parameters. So this is an issue, but this is also why core has a built-in dependency injection service. Basically what that means is that we say that for every IGuitarRepository, we want to use a certain concrete guitar repository. And we set this up inside of our startup class, inside of the configure services method. So inside of here we can say services and we would use a method called AddScoped in this case. For anything that is scoped, it is going to be used for a single request. And using this method is very simple. We supply two type parameters. The first is the type that we want the dependency injection service to look for. So basically for every time that we see IGuitarRepository. We want it to create an object of static guitar repository. And it couldn't be any simpler than that. We of course need a using statement for our data namespace. But once we do that, we will then be able to run this application and everything is going to work just fine. So if we do that, all we need to do is reload this page. Because if the index for our guitars doesn't work then nothing else is going to work. But this is going to work, because well, that's what the dependency injection service is for. Now you might think that's okay, that's great. But we still have to come in here and manually change the type of repository that we want to use. Well yes and no. We could write code like this. You can see that there is this environment object. And if it's the development environment, then we could use our static guitar repository. But if it's not that environment, then we could use something else. The only problem there is that we don't have a reference to that environment object. But we kind of do, because in the startup constructor we are giving that environment object. So we could create a field and store this environment in that field. So let's just say private readonly I hosting environments. Lets call this _env and then inside of the constructor we will say _env equals env. So now inside of our configure services we could use that object. If this is development, then we definitely want to use our static guitar repository, else we would use something else. So then it doesn't matter what environment we're in. Our application is going to use the guitar repository that it needs. And then we don't have to worry about it at all. So as you're writing or ASP.NET Core applications, use the dependency injection service. I mean, there's no reason not to. You will have better code because of it.

Back to the top