Utilisation d'un service Scoped dans un Singleton dans une application Asp.Net Core

Bien que Injection de dépendances: durée de vie des services La documentation dans ASP.NET Core dit:

Il est dangereux de résoudre un service de portée à partir d'un singleton. Cela peut entraîner un état incorrect du service lors du traitement des demandes ultérieures.

Mais dans votre cas, ce n'est pas le problème. En fait, vous ne résolvez pas le service de portée à partir de singleton. Il s'agit simplement d'obtenir une instance de service à portée de singleton chaque fois qu'il le souhaite. Votre code doit donc fonctionner correctement sans aucune erreur de contexte supprimée!

Mais une autre solution potentielle peut être l'utilisation de IHostedService . Voici les détails à ce sujet:

Utilisation d'un service de portée dans une tâche d'arrière-plan (IHostedService)

Ce que vous faites n'est pas bon et peut certainement entraîner des problèmes. Puisque cela est fait dans l'enregistrement du service, le service de portée va être récupéré une fois lorsque votre singleton est injecté pour la première fois. En d'autres termes, ce code ici ne s'exécutera qu'une fois pendant la durée de vie du service que vous enregistrez, ce qui, puisqu'il s'agit d'un singleton, signifie que cela ne se produira qu'une fois, point final. De plus, le contexte que vous injectez ici n'existe que dans la portée que vous avez créée, qui disparaît dès que l'instruction using se ferme. En tant que tel, au moment où vous essayez d'utiliser le contexte dans votre singleton, il aura été supprimé et vous obtiendrez une ObjectDisposedException .

Si vous avez besoin d'utiliser un service de portée à l'intérieur un singleton, vous devez alors injecter IServiceProvider dans le singleton. Ensuite, vous devez créer une portée et extraire votre contexte lorsque vous devez l'utiliser , et cela devra être fait chaque fois que vous en aurez besoin. Par exemple:

public class PersistedConfigurationService : IPersistedConfigurationService
{
    private readonly IServiceProvider _serviceProvider;

    public PersistedConfigurationService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task Foo()
    {
        using (var scope = _serviceProvider.CreateScope())
        {
             var context = scope.ServiceProvider.GetRequiredService<IPersistedConfigurationDbContext>();
             // do something with context
        }
    }
}

Juste pour souligner, encore une fois, vous devrez le faire dans chaque méthode qui doit utiliser le service de portée (votre contexte). Vous ne pouvez pas persister ceci à un ivar ou quelque chose. Si vous êtes découragé par le code, vous devriez l'être, car c'est un anti-modèle. Si vous devez obtenir un service de portée dans un singleton, vous n’avez pas le choix, mais le plus souvent, c’est un signe de mauvaise conception. Si un service a besoin d'utiliser des services étendus, il doit presque invariablement être scopé lui-même, pas singleton. Il n'y a que quelques cas où vous avez vraiment besoin d'une durée de vie unique, et ceux-ci tournent principalement autour de la gestion des sémaphores ou d'autres états qui doivent être persistés tout au long de la vie de l'application. À moins qu'il y ait une très bonne raison de faire de votre service un singleton, vous devriez opter pour scoped dans tous les cas; scoped doit être la durée de vie par défaut, sauf si vous avez une raison de faire autrement.

En regardant le nom de ce service - je pense que vous avez besoin d'un fournisseur de configuration personnalisé qui charge la configuration à partir de la base de données au démarrage (une seule fois). Pourquoi ne faites-vous pas quelque chose comme suivre à la place? C'est une meilleure conception, une approche plus conforme au cadre et aussi quelque chose que vous pouvez créer en tant que bibliothèque partagée dont d'autres personnes peuvent également bénéficier (ou dont vous pouvez bénéficier dans plusieurs projets).

public static class ConfigurationBuilderExtensions
{
    public static IConfigurationBuilder AddPersistentConfig(this IConfigurationBuilder configurationBuilder, string connectionString)
    {
          return configurationBuilder.Add(new PersistentConfigurationSource(connectionString));
    }

}

class PersistentConfigurationSource : IConfigurationSource
{
    public string ConnectionString { get; set; }

    public PersistentConfigurationSource(string connectionString)    
    {
           ConnectionString = connectionString;
    }

    public IConfigurationProvider Build(IConfigurationBuilder builder)
    {
         return new PersistentConfigurationProvider(new DbContext(ConnectionString));
    }

}

class PersistentConfigurationProvider : ConfigurationProvider
{
    private readonly DbContext _context;
    public PersistentConfigurationProvider(DbContext context)
    {
        _context = context;
    }


    public override void Load() 
    {
           // Using _dbContext
           // Load Configuration as valuesFromDb
           // Set Data
           // Data = valuesFromDb.ToDictionary<string, string>...
    }

}

Ici - AddPersistentConfig est une méthode d'extension construite comme une bibliothèque qui ressemble à ceci.

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
                .UseStartup<Startup>()
                .ConfigureAppConfiguration((context, config) =>
                {
                    var builtConfig = config.Build();
                    var persistentConfigBuilder = new ConfigurationBuilder();
                    var connectionString = builtConfig["ConnectionString"];
                    persistentStorageBuilder.AddPersistentConfig(connectionString);
                    var persistentConfig = persistentConfigBuilder.Build();
                    config.AddConfiguration(persistentConfig);
                });
}