Injection de dépendances ASP.NET Core Blazor

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();

Après avoir créé une application, examinez la méthode Startup.ConfigureServices dans Startup.cs :

using Microsoft.Extensions.DependencyInjection;

...

public void ConfigureServices(IServiceCollection services)
{
    ...
}

La méthode ConfigureServices est passée à une IServiceCollection, qui est une liste d’objets de descripteur de service. Les services sont ajoutés dans la méthode ConfigureServices en fournissant des descripteurs de service à la collection de services. L’exemple suivant illustre le concept avec l’interface IDataAccess et son implémentation concrète DataAccess :

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<IDataAccess, DataAccess>();
}

Services côté client qui échouent lors du prérendu

Cette section s’applique seulement aux composants WebAssembly dans les Blazor Web App.

Les Blazor Web App effectuent normalement le prérendu des composants WebAssembly côté client. Si une application est exécutée avec un service requis inscrit seulement dans le projet .Client, l’exécution de l’application génère une erreur de runtime similaire à l’erreur suivante quand un composant tente d’utiliser le service requis lors du prérendu :

InvalidOperationException : Impossible de fournir une valeur pour {PROPRIÉTÉ} sur le type « {ASSEMBLY}}.Client.Pages.{NOM DU COMPOSANT} ». Il n’existe pas de service inscrit de type « {SERVICE} ».

Pour résoudre ce problème, utilisez l’une des approches suivantes :

• Inscrivez le service dans le projet principal pour le rendre disponible lors de la prérendu des composants.
• Si le prérendu n’est pas requis pour le composant, désactivez le prérendu en suivant les instructions fournies dans Modes de prérendu d’ASP.NETBlazor. Si vous adoptez cette approche, vous n’avez pas besoin d’inscrire le service dans le projet principal.

Pour plus d’informations, consultez Les services côté client ne peuvent pas être résolus lors du prérendu.

Pour injecter des services dans des composants, Blazor prend en charge l’injection de constructeurs et l’injection de propriétés.

Injection de constructeurs

Une fois les services ajoutés à la collection de services, injectez un ou plusieurs services dans des composants avec l’injection de constructeur. L’exemple suivant injecte le service NavigationManager.

ConstructorInjection.razor :

@page "/constructor-injection"

<button @onclick="HandleClick">
    Take me to the Counter component
</button>

ConstructorInjection.razor.cs :

using Microsoft.AspNetCore.Components;

public partial class ConstructorInjection(NavigationManager navigation)
{
    private void HandleClick()
    {
        navigation.NavigateTo("/counter");
    }
}

Injection de propriétés

Injecter des services à clé dans les composants

Blazor prend en charge l’injection de services à clé à l’aide de l’attribut [Inject]. Les clés permettent de définir l’étendue de l'inscription et de la consommation des services lors de l'utilisation de l'injection de dépendances. Utilisez la propriété InjectAttribute.Key pour spécifier la clé du service à injecter :

[Inject(Key = "my-service")]
public IMyService MyService { get; set; }

@page "/time-travel"
@inject ITimeTravel TimeTravel1
@inherits OwningComponentBase

<h1><code>OwningComponentBase</code> Example</h1>

<ul>
    <li>TimeTravel1.DT: @TimeTravel1?.DT</li>
    <li>TimeTravel2.DT: @TimeTravel2?.DT</li>
</ul>

@code {
    private ITimeTravel TimeTravel2 { get; set; } = default!;

    protected override void OnInitialized()
    {
        TimeTravel2 = ScopedServices.GetRequiredService<ITimeTravel>();
    }
}

@page "/time-travel"
@inject ITimeTravel TimeTravel1
@inherits OwningComponentBase

<h1><code>OwningComponentBase</code> Example</h1>

<ul>
    <li>TimeTravel1.DT: @TimeTravel1?.DT</li>
    <li>TimeTravel2.DT: @TimeTravel2?.DT</li>
</ul>

@code {
    private ITimeTravel TimeTravel2 { get; set; } = default!;

    protected override void OnInitialized()
    {
        TimeTravel2 = ScopedServices.GetRequiredService<ITimeTravel>();
    }
}

Détecter les éléments jetables temporaires côté client

Vous pouvez ajouter du code personnalisé à une application Blazor côté client pour détecter les services temporaires jetables dans une application qui doit utiliser OwningComponentBase. Cette approche est utile si vous craignez que le code ajouté par la suite à l’application consomme un ou plusieurs services temporaires jetables, notamment des services ajoutés par des bibliothèques. Le code de démonstration est disponible dans les exemples de Blazorréférentiel GitHub des échantillons (comment télécharger).

Inspectez ce qui suit dans les versions .NET 6 et ultérieures de l’exemple BlazorSample_WebAssembly :

• DetectIncorrectUsagesOfTransientDisposables.cs
• Services/TransientDisposableService.cs
• Dans : Program.cs
  • L’espace de noms Services de l’application est fourni en haut du fichier (using BlazorSample.Services;).
  • DetectIncorrectUsageOfTransients est appelé immédiatement après l’attribution de builder à partir de WebAssemblyHostBuilder.CreateDefault.
  • TransientDisposableService est inscrit (builder.Services.AddTransient<TransientDisposableService>();).
  • EnableTransientDisposableDetection est appelé sur l’hôte généré dans le pipeline de traitement de l’application (host.EnableTransientDisposableDetection();).
• L’application inscrit le service TransientDisposableService sans lever d’exception. Toutefois, la tentative de résolution du service dans TransientService.razor lève InvalidOperationException quand l’infrastructure tente de construire une instance de TransientDisposableService.

Détecter les éléments jetables temporaires côté serveur

Vous pouvez ajouter du code personnalisé à une application Blazor côté serveur pour détecter les services temporaires jetables côté serveur dans une application qui doit utiliser OwningComponentBase. Cette approche est utile si vous craignez que le code ajouté par la suite à l’application consomme un ou plusieurs services temporaires jetables, notamment des services ajoutés par des bibliothèques. Le code de démonstration est disponible dans les exemples de Blazorréférentiel GitHub des échantillons (comment télécharger).

Inspectez ce qui suit dans les versions .NET 8 et ultérieures de l’exemple BlazorSample_BlazorWebApp :

Inspectez ce qui suit dans la version .NET 6 ou .NET 7 de l’exemple BlazorSample_Server :

• DetectIncorrectUsagesOfTransientDisposables.cs
• Services/TransitiveTransientDisposableDependency.cs :
• Dans : Program.cs
  • L’espace de noms Services de l’application est fourni en haut du fichier (using BlazorSample.Services;).
  • DetectIncorrectUsageOfTransients est appelé sur le générateur d’hôte (builder.DetectIncorrectUsageOfTransients();).
  • Le service TransientDependency est inscrit (builder.Services.AddTransient<TransientDependency>();).
  • TransitiveTransientDisposableDependency est inscrit pour ITransitiveTransientDisposableDependency (builder.Services.AddTransient<ITransitiveTransientDisposableDependency, TransitiveTransientDisposableDependency>();).
• L’application inscrit le service TransientDependency sans lever d’exception. Toutefois, la tentative de résolution du service dans TransientService.razor lève InvalidOperationException quand l’infrastructure tente de construire une instance de TransientDependency.

Inscriptions de services temporaires pour les gestionnaires IHttpClientFactory/HttpClient

Les inscriptions de service temporaires pour les gestionnaires IHttpClientFactory/HttpClient sont recommandées. Si l’application contient des gestionnaires IHttpClientFactory/HttpClient et utilise IRemoteAuthenticationBuilder<TRemoteAuthenticationState,TAccount> pour ajouter la prise en charge de l’authentification, les éléments temporaires supprimables suivants pour l’authentification côté client sont également découverts, ce qui est attendu et peut être ignoré :

• BaseAddressAuthorizationMessageHandler
• AuthorizationMessageHandler

D’autres instances de IHttpClientFactory/HttpClient sont également découvertes. Ces instances peuvent également être ignorées.

Les exemples d’applications Blazor dans le Blazorréférentiel GitHub d’échantillon (comment télécharger) illustrent le code pour détecter les jetables temporaires. Toutefois, le code est désactivé, car les exemples d’applications incluent des gestionnaires IHttpClientFactory/HttpClient.

Pour activer le code de démonstration et voir son fonctionnement :

• Supprimez les marques de commentaire des lignes correspondant aux éléments supprimables temporaires dans Program.cs.

• Supprimez la vérification conditionnelle dans NavLink.razor qui empêche le composant TransientService de s’afficher dans la barre latérale de navigation de l’application :

  - else if (name != "TransientService")
  + else
  

• Exécutez l’exemple d’application et accédez au composant TransientService dans /transient-service.

Les gestionnaires d’activités de circuit proposent une approche pour accéder aux services Blazor délimités à partir d’autres étendues d’injection de dépendances non Blazor, telles que les étendues créées à l’aide de IHttpClientFactory.

Avant la sortie d’ASP.NET Core dans .NET 8, l’accès aux services limités à un circuit à partir d’autres étendues d’injection de dépendances nécessitait l’utilisation d’un type de composant de base personnalisé. Avec les gestionnaires d’activités de circuit, il n’est pas nécessaire d’utiliser un type de composant de base personnalisé, comme le montre l’exemple suivant :

public class CircuitServicesAccessor
{
    static readonly AsyncLocal<IServiceProvider> blazorServices = new();

    public IServiceProvider? Services
    {
        get => blazorServices.Value;
        set => blazorServices.Value = value;
    }
}

public class ServicesAccessorCircuitHandler(
    IServiceProvider services, CircuitServicesAccessor servicesAccessor) 
    : CircuitHandler
{
    public override Func<CircuitInboundActivityContext, Task> CreateInboundActivityHandler(
        Func<CircuitInboundActivityContext, Task> next) => 
            async context =>
            {
                servicesAccessor.Services = services;
                await next(context);
                servicesAccessor.Services = null;
            };
}

public static class CircuitServicesServiceCollectionExtensions
{
    public static IServiceCollection AddCircuitServicesAccessor(
        this IServiceCollection services)
    {
        services.AddScoped<CircuitServicesAccessor>();
        services.AddScoped<CircuitHandler, ServicesAccessorCircuitHandler>();

        return services;
    }
}

Accédez aux services limités à un circuit en injectant le CircuitServicesAccessor là où il est nécessaire.

Pour voir un exemple qui montre comment accéder à AuthenticationStateProvider à partir d’un DelegatingHandler configuré à l’aide de IHttpClientFactory, consultez Autres scénarios de sécurité ASP.NET Core Blazor côté serveur.

Il peut arriver qu’un composant Razor appelle des méthodes asynchrones qui exécutent du code dans une autre étendue de DI. Sans l’approche appropriée, ces étendues de DI n’ont pas accès aux services de Blazor, comme IJSRuntime et Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage.

Par exemple, les instances HttpClient créées à l’aide de IHttpClientFactory ont leur propre étendue de service DI. Par conséquent, les instances HttpMessageHandler configurées sur le HttpClient ne peuvent pas injecter directement des services Blazor.

Créez une classe BlazorServiceAccessor qui définit un AsyncLocal, qui stocke BlazorIServiceProvider pour le contexte asynchrone actuel. Une instance BlazorServiceAccessor peut être acquise à partir d’une autre étendue de service DI pour accéder aux services Blazor.

BlazorServiceAccessor.cs :

internal sealed class BlazorServiceAccessor
{
    private static readonly AsyncLocal<BlazorServiceHolder> s_currentServiceHolder = new();

    public IServiceProvider? Services
    {
        get => s_currentServiceHolder.Value?.Services;
        set
        {
            if (s_currentServiceHolder.Value is { } holder)
            {
                // Clear the current IServiceProvider trapped in the AsyncLocal.
                holder.Services = null;
            }

            if (value is not null)
            {
                // Use object indirection to hold the IServiceProvider in an AsyncLocal
                // so it can be cleared in all ExecutionContexts when it's cleared.
                s_currentServiceHolder.Value = new() { Services = value };
            }
        }
    }

    private sealed class BlazorServiceHolder
    {
        public IServiceProvider? Services { get; set; }
    }
}

Pour définir automatiquement la valeur de BlazorServiceAccessor.Services lorsqu’une méthode de composant async est appelée, créez un composant de base personnalisé qui implémente à nouveau les trois points d’entrée asynchrones principaux dans le code de composant Razor :

• IComponent.SetParametersAsync
• IHandleEvent.HandleEventAsync
• IHandleAfterRender.OnAfterRenderAsync

La classe suivante illustre l’implémentation du composant de base.

CustomComponentBase.cs :

using Microsoft.AspNetCore.Components;

public class CustomComponentBase : ComponentBase, IHandleEvent, IHandleAfterRender
{
    private bool hasCalledOnAfterRender;

    [Inject]
    private IServiceProvider Services { get; set; } = default!;

    [Inject]
    private BlazorServiceAccessor BlazorServiceAccessor { get; set; } = default!;

    public override Task SetParametersAsync(ParameterView parameters)
        => InvokeWithBlazorServiceContext(() => base.SetParametersAsync(parameters));

    Task IHandleEvent.HandleEventAsync(EventCallbackWorkItem callback, object? arg)
        => InvokeWithBlazorServiceContext(() =>
        {
            var task = callback.InvokeAsync(arg);
            var shouldAwaitTask = task.Status != TaskStatus.RanToCompletion &&
                task.Status != TaskStatus.Canceled;

            StateHasChanged();

            return shouldAwaitTask ?
                CallStateHasChangedOnAsyncCompletion(task) :
                Task.CompletedTask;
        });

    Task IHandleAfterRender.OnAfterRenderAsync()
        => InvokeWithBlazorServiceContext(() =>
        {
            var firstRender = !hasCalledOnAfterRender;
            hasCalledOnAfterRender |= true;

            OnAfterRender(firstRender);

            return OnAfterRenderAsync(firstRender);
        });

    private async Task CallStateHasChangedOnAsyncCompletion(Task task)
    {
        try
        {
            await task;
        }
        catch
        {
            if (task.IsCanceled)
            {
                return;
            }

            throw;
        }

        StateHasChanged();
    }

    private async Task InvokeWithBlazorServiceContext(Func<Task> func)
    {
        try
        {
            BlazorServiceAccessor.Services = Services;
            await func();
        }
        finally
        {
            BlazorServiceAccessor.Services = null;
        }
    }
}

Tous les composants qui étendent CustomComponentBase automatiquement ont BlazorServiceAccessor.Services défini sur le IServiceProvider dans l’étendue de DI Blazor actuelle.

Enfin, dans le fichier Program, ajoutez le BlazorServiceAccessor en tant que service délimité :

builder.Services.AddScoped<BlazorServiceAccessor>();

Enfin, dans la méthode Startup.ConfigureServices de Startup.cs, ajoutez le BlazorServiceAccessor en tant que service délimité :

services.AddScoped<BlazorServiceAccessor>();

• Injection de service via un fichier d’importation de niveau supérieur (_Imports.razor) dans les Blazor Web App
• Injection de dépendances dans ASP.NET Core
• Conseils sur IDisposable pour les instances temporaires et partagées
• Injection de dépendances dans des vues dans ASP.NET Core
• Constructeurs principaux (Guide C#)

• Injection de dépendances dans ASP.NET Core
• Conseils sur IDisposable pour les instances temporaires et partagées
• Injection de dépendances dans des vues dans ASP.NET Core