Understanding Basic Blazor Components (Part 2)

 

Understanding Dependency Injection (DI)

DI is a software design pattern and a methodology for achieving Inversion of Control (IoC). IoC is a broad term that refers to the practice of indicating that a class requires an instance of another class, rather than allowing our classes to create an object themselves. We can express that our class needs either a particular class or a specific interface. The responsibility for creating the class lies elsewhere, and IoC determines which class will be instantiated. In the case of DI, it represents a type of IoC where an object (class instance) is supplied via constructors, parameters, or service lookups.

There are numerous benefits to implementing Dependency Injection (DI). Our dependencies are not tightly bound, allowing us to avoid creating an instance of another class within our own. Instead, we request an instance, facilitating easier test writing and enabling implementation changes based on different platforms.

The external dependencies will become more apparent as we need to provide them to the class. Additionally, we can define the method for instantiating the object in a centralized location. The dependency injection is configured in Startup.cs for Blazor Server and in Program.cs for WebAssembly.

We can configure the creation of objects in different ways, such as- Singleton, Scoped, and Transient.

Singleton

When employing the singleton pattern, a single instance of the object will be utilized by all users on our site. This object is instantiated only once. The singleton pattern is beneficial when we aim to allow all users to access the same object; however, caution is needed as the shared state means that data pertaining to individual users or their preferences should not be stored, as this would impact all users.

Scoped

When using scoped, a new instance of an object is generated for each connection, and since Blazor Server relies on a connection, this object will remain the same as long as the user maintains that connection. In contrast, WebAssembly does not recognize the concept of scoped because it operates entirely within the user's web browser without any connections. Therefore, if scoped is implemented in Blazor WebAssembly, it will function similarly to a singleton. However, it is still advisable to use scoped if the intention is to limit the service to the current user.

Transient

When utilizing transient, a fresh object will be generated each time we request it. We should opt for transient when we don’t require any state maintenance and are okay with the object being created new every time it’s requested.

Injecting The Service

There are three ways to inject a service. In the first method, we can use the @inject directive in the Razor file. This will make sure we have access to WeatherForecastService in our component. The second way is to create a property by adding the Inject attribute if we are using code-behind. The third way is if we want to inject a service into another service, then we need to inject the services using the constructor.

Conclusion

Now we know how DI works and why we should use it.