Wie verwende ich ASP.NET Core App-Einstellungen mit einfachem Injektor

Question

Ich bin neu in ASP.NET Core und brauche eine gewisse Richtung. Ich versuche, ein einfaches Szenario mit der Verwendung von App-Einstellungen in ASP.NET Core, während auch Simple Injector verwenden.

Ich habe zuerst meine Strongly-Type Konfigurationseinstellungen wie erklärt here von Rick Strahl. Das funktioniert großartig.

public class MySettings 
    { 
    public string ApplicationName { get; set; } 
    } 

appsetting.json

{ 
    "Logging": { 
    "IncludeScopes": false, 
    "LogLevel": { 
     "Default": "Debug", 
     "System": "Information", 
     "Microsoft": "Information" 
    } 
    }, 
    "MySettings": { 
    "ApplicationName": "Test Service" 
    } 
} 

Startup.cs

public void ConfigureServices(IServiceCollection services) 
    { 
     // Add framework services. 
     services.AddMvc(); 

     // Add Options 
     services.AddOptions(); 

     // Add our Config object so it can be injected 
     services.Configure<MySettings>(Configuration.GetSection("MySettings")); 
     services.AddSingleton(GetTestBroker(container)); 

     //Simple Injector  
     //services.AddSingleton<IControllerActivator>(new SimpleInjectorControllerActivator(container)); 
     //services.AddSingleton<IViewComponentActivator>(new SimpleInjectorViewComponentActivator(container)); 


    } 

In unseren anderen Projekten wurden, werden über das Simple Injector für DI. Nachdem ich das Simple Injector-Paket hinzugefügt und es gemäß den Anweisungen konfiguriert habe, sehe ich, dass meine IOptions-Konfiguration abbricht.

Was würde ich gerne wissen, was wäre die beste Vorgehensweise für die Implementierung einer Konfiguration in ASP.NET Core und die Verwendung einer anderen DI-Bibliothek wie Simple Injector zusammen?

Answer 1

Die ASP.NET Core integration guide for Simple Injector besagt Folgendes:

ASP.NET-Core enthält eine neue Modellkonfiguration basiert auf einer IOption<T> Abstraktion. Wir raten davon ab, IOption<T> Abhängigkeiten in Ihre Anwendungskomponenten zu injizieren. Lassen Sie stattdessen Komponenten direkt von Konfigurationsobjekten abhängig und registrieren Sie sie als Singleton. Dadurch wird sichergestellt, dass die Konfigurationswerte während des Starts der Anwendung gelesen werden und sie zu diesem Zeitpunkt überprüft werden können, sodass die Anwendung schnell ausfällt.

Die Anwendung von Komponenten abhängig von IOptions<T> hat einige unglückliche Nachteile. Zuallererst führt dies dazu, dass Anwendungscode eine unnötige Abhängigkeit von einer Framework-Abstraktion eingeht. Dies ist eine Verletzung des Dependency Injection-Prinzips, das die Verwendung anwendungsspezifischer Abstraktionen vorschreibt. Das Einfügen einer IOptions<T> in eine Anwendungskomponente erschwert nur das Testen dieser Komponente, bietet jedoch keine Vorteile. Anwendungskomponenten sollten stattdessen direkt von den Konfigurationswerten abhängen, die sie benötigen.

IOptions<T> Konfigurationswerte werden langsam gelesen. Obwohl die Konfigurationsdatei beim Start der Anwendung gelesen werden kann, wird das erforderliche Konfigurationsobjekt nur erstellt, wenn IOptions<T>.Value zum ersten Mal aufgerufen wird. Wenn die Deserialisierung aufgrund einer falschen Konfiguration der Anwendung fehlschlägt, wird ein solcher Fehler erst nach dem Aufruf von IOptions<T>.Value angezeigt. Dies kann dazu führen, dass Fehlkonfigurationen viel länger als erforderlich unerkannt bleiben. Durch das Lesen und Überprüfen von Konfigurationswerten beim Start der Anwendung kann dieses Problem verhindert werden. Konfigurationswerte können als Singletons in die Komponente injiziert werden, die sie benötigt.

Um alles noch schlimmer zu machen, Sie im Fall vergessen, einen bestimmten Abschnitt zu konfigurieren (durch einen Aufruf an services.Configure<T> Weglassen), oder wenn Sie einen Tippfehler machen, während der Konfiguration Abschnitt Abrufen (durch den falschen Namen zu Configuration.GetSection(name) Versorgung), das Konfigurationssystem wird die Anwendung einfach mit einem Standardobjekt und einem leeren Objekt versorgen, anstatt eine Ausnahme auszulösen! Dies kann in einigen Fällen sinnvoll sein, führt jedoch leicht zu fragilen Anwendungen.

Da Sie die Konfiguration beim Start überprüfen möchten, ist es nicht sinnvoll, das Lesen zu verzögern, und das macht die Eingabe von IOption in Ihre Komponenten einfach falsch.Abhängig von IOptions<T> könnte immer noch nützlich sein, wenn Sie die Anwendung starten, aber nicht als eine Abhängigkeit irgendwo anders.

Sobald Sie ein richtig gelesen und verifiziert Konfigurationsobjekt haben, die Registrierung der Komponente, die das Konfigurationsobjekt erfordert, ist so einfach wie diese:

MyMailSettings mailSettings = 
    config.GetSection("Root:SectionName").Get<MyMailSettings>(); 

// Verify mailSettings here (if required) 

container.Register<IMessageSender>(() => new MailMessageSender(mailSettings)); 

Answer 2

Ich bin der Autor von ExistAll.SimpleConfig. SimpleConfig ist genau das, was für die Konfiguration/Einstellungen in einer DI-Umgebung benötigt wird.

Werfen Sie einen Blick zu sehen, ob es was Sie