Retrieving Services from Dependency Injection in .NET

Introduction

Dependency Injection (DI) is a critical part of .NET since the .NET Core days. A simple, although powerful, DI container is included out of the box, and ASP.NET Core makes heavy use of it.

I already wrote about DI in .NET a few times:

This time I want to highlight something that people may not be aware of, even though I already mentioned it in one of my posts.

Retrieving Services

As you know, the DI is represented by an instance of IServiceProvider. When we want to retrieve a service we call GetService, passing it a Type, for a dynamic call, or GetService<T>, for a strongly-typed version, which just calls the other one with a cast.

Now, if the service represented by the Type or the T generic template parameter is not registered, GetService will return null. If we want to force the service to exist or fail, we call GetRequiredService<T>, which will throw an exception if the service is not registered. If we don't know for sure, GetService or GetService<T> are safer.

As you may know, we can register multiple implementations, even with different lifetimes, for the same service. If we want to retrieve all registrations that possibly exist - even if it's none - we can call GetServices<T>, which is the same as calling GetService<IEnumerable<T>>. This will return an enumeration of all registrations, which can possibly be empty, but won't throw.

Constructor Injection

One thing that you need to be careful is: when injecting a service into a class' constructor, that service needs to be registered, which means, it is treated as if GetRequiredService<T> is used, dependencies must always be registered. For example:

public class ExternalClass(InternalClass obj) { ... }
...
services.AddSingleton<ExternalClass>();  //InternalClass is not registered
...
serviceProvider.GetService<ExternalClass>();    //throws an exception
serviceProvider.GetServices<InternalClass>();   //returns an empty array of InternalClass

In general, I recommend constructor injection instead of retrieving services from the DI - the service locator approach, which some people think is an anti-pattern, not my opinion, though, I think there may be some valid use cases for it.

Scopes

Another thing that is probably obvious is, you cannot inject a service defined as scoped into another registered as singleton, even indirectly, from transient instances. In general, when you need a scoped service outside of a scope, you need first to create a scope and dispose of it at the end of the constructor or method:

using var scope = serviceProvider.CreateScope();
...
scope.ServiceProvider.GetRequiredService<SomeScopedService>();

CreateScope/CreateAsyncScope are actually just extension methods that retrieve an IServiceScopeFactory instance from DI and call its CreateScope method, creating a new IServiceScope. Because there is no way to know if the service provider you are using is already inside a scope, it's better to create one when in doubt. All services registered as scoped will only be instantiated once and cached for the same scope. Don't forget to dispose of the scope when you no longer need it. ASP.NET Core automatically creates a scope for each request and disposes of it at the end. All disposable services instantiated from a scope will too be disposed of with the scope.

Validation

The .NET DI container can validate the lifetime dependencies at construction or upon request, if you pass the appropriate values:

var serviceProvider = services.BuildServiceProvider(new ServiceProviderOptions { ValidateOnBuild = true, ValidateScopes = true });

ServiceProviderOptions has two properties, ValidateScopes, which does the validation of scope dependencies, and ValidateOnBuild which does it when the service provider (the IServiceProvider instance) is actually built (BuildServiceProvider), rather than when a service is requested. The defaults for these properties are both true if running in development environment, and false otherwise.

If you want to learn more, please read the official Microsoft guidelines for DI here.

Conclusion

As always, happy to hear your thoughts on this topic!

Location: Coimbra, Portugal

Comments

Post a Comment

Popular posts from this blog

OpenTelemetry with ASP.NET Core

Image
Introduction I wrote a post not too long ago about the building blocks of telemetry , or distributed tracing , with ASP.NET Core. Now I'm going to talk about how we can see it working using an open source bundle, otel-lgtm . Mind you, this may not be 100% suitable for production, but for development purposes, it should be fine, all concepts apply, of course. I won't cover everything about OpenTelemetry here, but should hopefully give you some insights as to what's there and how you can make good use of it. First, lets see what some of the concepts are. If you're interested in learning more about metrics, I suggest having a look at my post on this topic . OpenTelemetry OpenTelemetry  (OTel) provides a single, open-source standard, and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure. OTel is both a standard and a reference implementation that builds on other standards, such as W3C Distributed Tr...
Read more

ASP.NET Core Middleware

Image
Introduction This post is another of those "back to basics", still, there was one thing or two that I feel were not properly discussed elsewhere, hence this post. The ASP.NET Core Pipeline and Middleware You may know that ASP.NET Core defines a pipeline. This is where the incoming requests are processed and the response submitted. Each component in the pipeline - a middleware - can do things with the message (the request), such as check if it is authenticated and have rights to access the requested resource, turn the request into an MVC-style controller and action invocation, log it, and what not. You can read more about it here . The ASP.NET Core pipeline, from Microsoft The order by which the middleware is added to the pipeline matters. For example, the authorisation middleware must come after the authentication one, static files must come before routing, and exception handling must come before everything. The middleware order, from Microsoft A middleware is just a piece of...
Read more

.NET Cancellation Tokens

Introduction Cancellation tokens in .NET were introduced as part of the  .NET 4 Cancellation Framework . Essentially, it is a standard, cooperative, way to request for the cancellation of the execution of an operation. By cooperative it means that the code that uses it must abide to some rules, as opposed to the cancellation just stopping (killing) the execution. One example of cancellation is, on a web app, when the client closes the connection while the server is performing some long operation. In cases such as this, we may want to abort the operation, as we are not sending the results anywhere (or not, as we shall see). Because of this, ASP.NET Core allows us to add a parameter of type  CancellationToken  to our asynchronous actions, it is automatically associated with the client and is therefore signalled when the client connection is closed. A  CancellationToken  is, essentially, behind the scenes, a ManualResetEvent . Throughout this article I will either ...
Read more