web-dev-qa-db-fra.com

Approche simplifiée pour les options <T>

J'essaie d'obtenir une bibliothèque de classes .NET Framework en ligne avec une application ASP.NET Core 2.1 tout en utilisant le mécanisme DI intégré. Maintenant, j'ai créé une classe de configuration et ajouté la section appropriée à appsettings.json:

services.Configure<MyConfig>(Configuration.GetSection("MyConfiguration"));
services.AddScoped<MyService>();

En classe lib: 

public class MyService 
{
    private readonly MyConfig _config;

    public MyService(IOptions<MyConfig> config)
    {
        _config = config.Value;
    }
}

Cependant, pour construire cette classe, je dois ajouter le package Microsoft.Extensions.Options NuGet. Le problème est que ce paquet comporte de nombreuses dépendances qui semblent plutôt excessives à ajouter pour le seul intérêt d’une interface. 

 enter image description here

La question qui se pose est donc la suivante: «y at-il une autre approche que je peux adopter pour configurer un service DI situé dans la bibliothèque de classes .NET Framework qui n’est pas très dépendant des dépendances?

asp.net-coredependency-injectionasp.net-core-2.1.net-4.7.1
8
mmix

Consultez cet article écrit par Filip Wojcieszyn.

https://www.strathweb.com/2016/09/configuration-en-typée-en-typée-net-core-sans-ioption

Vous ajoutez une méthode d'extension:

public static class ServiceCollectionExtensions
{
    public static TConfig ConfigurePOCO<TConfig>(this IServiceCollection services, IConfiguration configuration) where TConfig : class, new()
    {
        if (services == null) throw new ArgumentNullException(nameof(services));
        if (configuration == null) throw new ArgumentNullException(nameof(configuration));

        var config = new TConfig();
        configuration.Bind(config);
        services.AddSingleton(config);
        return config;
    }
}

Appliquez-le en configuration:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.ConfigurePOCO<MySettings>(Configuration.GetSection("MySettings"));
}

Et puis utilisez-le:

public class DummyService
{
    public DummyService(MySettings settings)
    {
        //do stuff
    }
}
4
Slawomir Brys

Je suis tombé sur ce problème il y a quelques instants, si vous pouvez même l'appeler un problème vraiment. Je pense que nous avons tous tendance à être un peu choqués par Shell lorsque nous voyons une telle liste de dépendances. Mais, comme @Tseng l’a mentionné, il n’est vraiment pas très compliqué d’inclure un ensemble d’assemblages minuscules supplémentaires (ils seront déjà inclus dans bin de toute façon en vertu d’une référence dans un autre projet). Mais je dois admettre que c'est agaçant de devoir les inclure uniquement pour l'interface des options.

Comment j'ai résolu le problème en résolvant la dépendance du service dans startup.cs et en ajustant le constructeur du service en conséquence:

services.AddTransient<MyService>(Configuration.GetConfiguration("MyConfiguration"));
1
pimbrouwers

Si vous ne vous souciez pas de ce que IOptions vous fournit, pourquoi ne pas simplement injecter IConfiguration dans votre service?

public class MyService
{
    private readonly IConfiguration _config;

    public MyService(IConfiguration config)
    {
        _config = config;
    }

    public void DoSomething()
    {
        var value = _config["SomeKey"];

        // doing something
    }
}
0
TheBlueSky