wake-up-neo.com

Vereinfachter Ansatz für IOptions <T>

Ich versuche, eine .NET Framework-Klassenbibliothek mit einer ASP.NET Core 2.1-Anwendung in Einklang zu bringen, während der eingebaute DI-Mechanismus verwendet wird. Jetzt habe ich eine config-Klasse erstellt und zu appsettings.json einen entsprechenden Abschnitt hinzugefügt:

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

In der Klasse lib: 

public class MyService 
{
    private readonly MyConfig _config;

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

Um diese Classlib zu erstellen, muss ich jedoch das Microsoft.Extensions.Options-NuGet-Paket hinzufügen. Das Problem ist, dass das Paket eine Menge von Abhängigkeiten hat, die nur aus Gründen einer Schnittstelle etwas übertrieben erscheinen. 

 enter image description here

Letztendlich lautet die Frage: "Gibt es einen anderen Ansatz, um einen DI-Dienst zu konfigurieren, der sich in der .NET Framework-Klassenbibliothek befindet, der nicht stark abhängig ist?"

8
mmix

Überprüfen Sie diesen Artikel von Filip Wojcieszyn.

https://www.strathweb.com/2016/09/strongly-typed-configuration-in-asp-net-core-without-ioptionst/

Sie fügen eine Erweiterungsmethode hinzu:

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;
    }
}

Übernehmen Sie es in der Konfiguration:

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

Und dann benutze es:

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

Ich bin vor einiger Zeit auf dieses Problem gestoßen, wenn man es wirklich als Problem bezeichnen kann. Ich denke, wir neigen alle dazu, ein wenig Shell-Schock zu bekommen, wenn wir eine solche Abhängigkeitsliste sehen. Aber, wie @Tseng erwähnt hat, ist es wirklich keine große Sache, ein paar extra winzige Assemblies einzubauen (diese werden ohnehin schon in der Variable bin enthalten). Aber ich muss zugeben, dass es ärgerlich ist, sie nur für die Optionsschnittstelle verwenden zu müssen.

Wie ich es gelöst habe, war, die Dienstabhängigkeit in startup.cs aufzulösen und den Konstruktor des Dienstes entsprechend anzupassen:

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

Wenn Sie sich nicht für das interessieren, was Ihnen IOptions zur Verfügung stellt, können Sie IConfiguration nicht einfach in Ihren Dienst einbinden.

public class MyService
{
    private readonly IConfiguration _config;

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

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

        // doing something
    }
}
0
TheBlueSky