Dependency Injection in Blazor

In this segment, you will learn how to use dependency injection in Blazor. You will do so by getting familiar with how to use standard in-built ASP.NET Core dependency injection mechanism and also by using third party dependency injection containers.

Dependency injection, also known as inversion of control, is a mechanism that allows you to inject dependencies into various components in software. When you use standard classes in C#, a dependency injection is done via the constructor of the class. In Razor components inside of Blazor, however, dependency injection can either be done via constructor if you have your code separate from the markup, or you can use inject directive, as we are using in FetchData Razor file. And inside our counter Razor file, where we are injecting IJS runtime interface.

When we have a look at the FetchData example, in here, we are injecting a concrete implementation of WeatherForecastService However, in counter Razor, we are injecting an interface. So how injecting interface would actually work? After all, interfaces are completely meaningless without implementation.

Well, when you launch your application, it’s not the interface that will be injected into this class. It will be some class that implements this interface. And it’s your upstream dependency registration system that will decide which class it is.

In our case here, it is this directive that, behind the scene, applies all relevant mappings between various interfaces and their concrete implementations. Also, please note this line here, where we adding a weather forecast service are singleton. This means that we are using only one instance of weather forecast service within the entire application. And this registration is precisely what allows us to inject weather forecast service into FetchData Razor class.

This is one way of using dependency injection. However, if we have a look at the definition of weather forecast service, there is an obvious disadvantage of injecting a concrete implementation. We always have to rely on the real data that this implementation produces. This is why it’s always better to add an interface that this weather forecast service would implement.

To do so, I will create a new object within the same folder where WeatherForecastService is located. And by following the standard C# naming conventions, I will call it IWeatherForecastService The interface will have only one accessible member. And now, WeatherForecastService will implement this interface. Now, I will replace concrete implementation with an interface.

The last thing that I need to do now is to map the interface to the concrete implementation. So this is what I’ve done. I have registered WeatherForecastService as the only implementation for IWeatherForecastService forecast interface. And I’ve registered it as a singleton.

So now, whenever our runtime will see this interface, it will automatically resolve it to WeatherForecastService Functionally, in our application, we haven’t changed anything. However, we have now gained ability to inject an alternative implementation of this interface.

For example, if you want to write unit tests, you can just mock up this interface if the concrete implementation is not crucial for your unit tests. And just to prove that we haven’t changed anything functionally, we will launch our application. And just like we expected, the page is identical to what it was before.

As well as relying on the standard ASP.NET Core dependency injection mechanism, Blazor allows you to use third party dependency injection frameworks. Their usage is identical to how you would use them in any other type of ASP.NET Core application. To show you an example, we are using the following NuGet packages. We have added Autofac, which is a very popular dependency injection framework used in .NET. And we have added a related package– Autofac.Extensio ns.DependencyInjection.

To register this package, we just need to add an extra line to our create host builder method inside of our program class. We’re just adding a call to use service provider factoring methods with new AutofacServiceProviderFactory as an argument. And then in our startup class, we have removed the registration of WeatherForecastService from our ConfigureServices() method. And we’ve added the following method– ConfiguewContainer ContainerBuilder is a parameter that will be passed into it.

If we hover over it, you can see that it comes from Autofac NuGet package. And here is how we register the type. So any interfaces that this type implements will be resolved to this type. So functionally, it will work exactly as it did before, which we will verify by launching the application. And this, indeed, is the case.

You may ask why would you need to use third party dependency injection containers if ASP.NET Core provides a dependency injection mechanism out of the box. Well, those third party frameworks allow you much more flexibility with your dependency injection, while out of the box mechanism is very limited. Yes, quite often, built-in mechanism is all you need. But there will be use cases where third party solutions are much better.