Anwendungsfälle für die Konfiguration in ASP.NET Core

Um die Konfiguration der Anwendung zu erhalten, wird häufig die Zugriffsmethode nach Schlüsselwort (Schlüsselwert) verwendet. Dies ist jedoch nicht immer bequem. Manchmal müssen Sie vorgefertigte Objekte in Ihrem Code mit bereits festgelegten Werten verwenden und Werte aktualisieren können, ohne die Anwendung neu zu starten. Dieses Beispiel enthält eine Vorlage für die Verwendung der Konfiguration als Middleware für ASP.NET Core-Anwendungen.



Es wird empfohlen, sich zunächst mit dem Material vertraut zu machen: Metanit - Konfiguration , Funktionsweise der Konfiguration in .NET Core .

Formulierung des Problems

Sie müssen eine ASP NET Core-Anwendung implementieren, mit der die Konfiguration zur Laufzeit im JSON-Format aktualisiert werden kann. Während eines Konfigurationsupdates sollten die aktuell ausgeführten Sitzungen weiterhin mit den vorherigen Konfigurationsoptionen funktionieren. Nach dem Aktualisieren der Konfiguration müssen die verwendeten Objekte aktualisiert / durch neue ersetzt werden.



Die Konfiguration muss deserialisiert werden, es darf kein direkter Zugriff auf IConfiguration-Objekte von Controllern aus erfolgen. Die gelesenen Werte sollten auf ihre Richtigkeit überprüft werden. Wenn sie nicht vorhanden sind, sollten sie durch Standardwerte ersetzt werden. Die Implementierung sollte in einem Docker-Container funktionieren.

Klassische Konfigurationsarbeit

GitHub: ConfigurationTemplate_1



Das Projekt basiert auf der ASP NET Core MVC-Vorlage. Der Konfigurationsanbieter JsonConfigurationProvider wird zum Arbeiten mit JSON-Konfigurationsdateien verwendet . Fügen Sie den Parameter "reloadOnChange: true" hinzu, um die Anwendungskonfiguration während des Betriebs neu laden zu können. Ersetzen Sie



in der Datei Startup.cs Folgendes :

public Startup(IConfiguration configuration)
 {
   Configuration = configuration;
 }

Auf

public Startup(IConfiguration configuration)
 {         
   var builder = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
   configuration = builder.Build();
   Configuration = configuration;
  }

.AddJsonFile - fügt eine JSON-Datei hinzu, reloadOnChange: true gibt an, dass die Parameter der Konfigurationsdatei beim Ändern neu geladen werden, ohne dass die Anwendung neu geladen werden muss.



Inhalt der Datei appsettings.json :

{
  "AppSettings": {
    "Parameter1": "Parameter1 ABC",
    "Parameter2": "Parameter2 ABC"  
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

Anwendungscontroller verwenden den Dienst: ServiceABC, anstatt direkt auf die Konfiguration zuzugreifen. ServiceABC ist eine Klasse, die Anfangswerte aus der Konfigurationsdatei übernimmt. In diesem Beispiel enthält die ServiceABC- Klasse nur eine Title- Eigenschaft . Inhalt der ServiceABC.cs-



Datei :

public class ServiceABC
{
  public string Title;
  public ServiceABC(string title)
  {
     Title = title;
  }
  public ServiceABC()
  { }
}

Um ServiceABC verwenden zu können, müssen Sie es Ihrer Anwendung als Middleware-Dienst hinzufügen. Fügen Sie den Dienst als AddTransient hinzu, der bei jedem Zugriff mit dem folgenden Ausdruck erstellt wird:

services.AddTransient<IYourService>(o => new YourService(param));

Ideal für einfache Dienste, die weder Speicher noch Ressourcen verbrauchen. Das Lesen der Konfigurationsparameter in Startup.cs erfolgt mit IConfiguration , das eine Abfragezeichenfolge verwendet , die den vollständigen Pfad des Werteverzeichnisses angibt, z. B.: AppSettings: Parameter1. Fügen Sie in der



Datei Startup.cs Folgendes hinzu:

public void ConfigureServices(IServiceCollection services)
{
  //  "Parameter1"    ServiceABC
  var settingsParameter1 = Configuration["AppSettings:Parameter1"];
  //  "Parameter1"            
  services.AddScoped(s=> new ServiceABC(settingsParameter1));
  //next
  services.AddControllersWithViews();
}

Als Beispiel für die Verwendung des ServiceABC- Dienstes in einem Controller wird der Wert Parameter1 auf der HTML-Seite angezeigt.



Um den Dienst in Controllern zu verwenden, fügen Sie ihn dem Konstruktor hinzu, Datei HomeController.cs

public class HomeController : Controller
{
  private readonly ILogger<HomeController> _logger;
  private readonly ServiceABC _serviceABC;
  public HomeController(ILogger<HomeController> logger, ServiceABC serviceABC)
    {
      _logger = logger;
      _serviceABC = serviceABC;
    }
  public IActionResult Index()
    {
      return View(_serviceABC);
    }

Service-Sichtbarkeit hinzufügen ServiceABC- Datei _ViewImports.cshtml

@using ConfigurationTemplate_1.Services

Ändern Sie Index.cshtml , um die Seite Parameter1 anzuzeigen .

@model ServiceABC
@{
    ViewData["Title"] = "Home Page";
}
    <div class="text-center">
        <h1>   ASP.NET Core</h1>
        <h4>   </h4>
    </div>
<div>        
    <p> ServiceABC,  
          Parameter1 = @Model.Title</p>
</div>

Beginnen wir mit der Anwendung:

Ergebnis

Dieser Ansatz löst das Problem teilweise. Diese Lösung erlaubt keine Anwendung von Konfigurationsänderungen, während die Anwendung ausgeführt wird. Der Dienst empfängt den Wert der Konfigurationsdatei erst beim Start und arbeitet dann nur mit dieser Instanz. Infolgedessen führen nachfolgende Änderungen an der Konfigurationsdatei nicht zu Änderungen an der Anwendung.

Verwenden von IConfiguration als Singleton

GitHub: ConfigurationTemplate_2 Die



zweite Option besteht darin, IConfiguration (als Singleton) in Dienste zu integrieren. Infolgedessen kann IConfiguration von Controllern und anderen Diensten aufgerufen werden. Bei Verwendung von AddSingleton wird der Dienst einmal erstellt, und bei Verwendung der Anwendung wird der Aufruf an dieselbe Instanz gesendet. Verwenden Sie diese Methode mit äußerster Vorsicht, da Speicherlecks und Multithreading-Probleme auftreten können.



Ersetzen wir den Code aus dem vorherigen Beispiel in Startup.cs durch einen neuen, wobei

services.AddSingleton<IConfiguration>(Configuration);

fügt IConfiguration als Singleton zu den Dienstleistungen.

public void ConfigureServices(IServiceCollection services)
{
  //  IConfiguration     
  services.AddSingleton<IConfiguration>(Configuration);
  //  "ServiceABC"                          
  services.AddScoped<ServiceABC>();
  //next
  services.AddControllersWithViews();
}

Ändern Sie den Konstruktor des ServiceABC- Dienstes , um die IConfiguration zu akzeptieren

public class ServiceABC
{        
  private readonly IConfiguration _configuration;
  public string Title => _configuration["AppSettings:Parameter1"];        
  public ServiceABC(IConfiguration Configuration)
    {
      _configuration = Configuration;
    }
  public ServiceABC()
    { }
}

Starten wir die Anwendung:







Der mit AddScoped zum Container hinzugefügte ServiceABC- Dienst bedeutet, dass bei jeder Seitenanforderung eine Instanz der Klasse erstellt wird. Infolgedessen wird bei jeder http-Anforderung zusammen mit dem erneuten Laden der IConfiguration- Konfiguration eine Instanz der ServiceABC- Klasse erstellt und neue Änderungen in appsettings.json werden angewendet. Wenn Sie also während des Betriebs der Anwendung den Parameter Parameter1 auf „NEU !!! Parameter1 ABC “wird beim nächsten Zugriff auf die Startseite der neue Parameterwert angezeigt. Lassen Sie uns die Seite aktualisieren, nachdem Sie die Datei appsettings.json geändert haben :

Ergebnis

Der Nachteil dieses Ansatzes ist das manuelle Lesen jedes Parameters. Wenn Sie eine Parameterüberprüfung hinzufügen, wird die Überprüfung nicht nach dem Ändern der Datei appsettings.json durchgeführt, sondern jedes Mal, wenn Sie ServiceABC verwenden. Dies ist eine unnötige Aktion. Im besten Fall sollten die Parameter nach jeder Dateiänderung nur einmal überprüft werden.

Konfigurationsdeserialisierung mit Validierung (Option IOptions)

GitHub: ConfigurationTemplate_3

Lesen Sie mehr über Optionen hier .



Diese Option macht die Verwendung von ServiceABC überflüssig . Stattdessen wird die AppSettings- Klasse verwendet , die die Einstellungen aus der Konfigurationsdatei und dem ClientConfig- Objekt enthält . Das ClientConfig-Objekt muss nach dem Ändern der Konfiguration initialisiert werden, weil In Controllern wird ein fertiges Objekt verwendet.

ClientConfig ist eine Klasse, die mit externen Systemen interagiert, deren Code nicht geändert werden kann. Wenn Sie nur die Daten der AppSettings- Klasse deserialisieren , dann ClientConfigwird null sein. Daher ist es erforderlich, das Lesekonfigurationsereignis zu abonnieren und das ClientConfig- Objekt im Handler zu initialisieren .



Um die Konfiguration nicht in Form von Schlüssel-Wert-Paaren, sondern als Objekte bestimmter Klassen zu übertragen, verwenden wir die IOptions- Schnittstelle . Darüber hinaus können Sie mit IOptions im Gegensatz zu ConfigurationManager einzelne Abschnitte deserialisieren. Um ein erstellen ClientConfig Objekt, Sie müssen verwenden IPostConfigureOptions , der ausgeführt wird , nachdem alle Konfiguration verarbeitet wurde. IPostConfigureOptions wird jedes Mal ausgeführt, wenn die Konfiguration zuletzt gelesen wurde.



Erstellen wir ClientConfig.cs :

public class ClientConfig
{
  private string _parameter1;
  private string _parameter2;
  public string Value => _parameter1 + " " + _parameter2;
  public ClientConfig(ClientConfigOptions configOptions)
    {
      _parameter1 = configOptions.Parameter1;
      _parameter2 = configOptions.Parameter2;
    }
}

Als Konstruktor werden Parameter in Form eines ClientConfigOptions- Objekts verwendet :

public class ClientConfigOptions
{
  public string Parameter1;
  public string Parameter2;
} 

Erstellen wir die AppSettings- Einstellungsklasse und definieren darin die ClientConfigBuild () -Methode , mit der das ClientConfig- Objekt erstellt wird . AppSettings.cs-



Datei :

public class AppSettings
{        
  public string Parameter1 { get; set; }
  public string Parameter2 { get; set; }        
  public ClientConfig clientConfig;
  public void ClientConfigBuild()
    {
      clientConfig = new ClientConfig(new ClientConfigOptions()
        {
          Parameter1 = this.Parameter1,
          Parameter2 = this.Parameter2
        }
        );
      }
}

Erstellen wir einen Konfigurationshandler, der zuletzt verarbeitet wird. Dazu muss es von IPostConfigureOptions geerbt werden . Die zuletzt aufgerufene PostConfigure führt ClientConfigBuild () aus , wodurch ClientConfig erstellt wird .



Datei ConfigureAppSettingsOptions.cs :

public class ConfigureAppSettingsOptions: IPostConfigureOptions<AppSettings>
{
  public ConfigureAppSettingsOptions()
    { }
  public void PostConfigure(string name, AppSettings options)
    {            
      options.ClientConfigBuild();
    }
}

Jetzt müssen nur noch Änderungen in Startup.cs vorgenommen werden. Die Änderungen wirken sich nur auf die Funktion ConfigureServices (IServiceCollection-Dienste) aus .



Lesen wir zunächst den Abschnitt AppSettings in appsettings.json

// configure strongly typed settings objects
var appSettingsSection = Configuration.GetSection("AppSettings");
services.Configure<AppSettings>(appSettingsSection);

Außerdem wird für jede Anforderung eine Kopie von AppSettings erstellt, sodass die Nachbearbeitung aufgerufen werden kann:

services.AddScoped(sp => sp.GetService<IOptionsSnapshot<AppSettings>>().Value);

Fügen wir eine Nachbearbeitung der AppSettings-Klasse als Service hinzu:

services.AddSingleton<IPostConfigureOptions<AppSettings>, ConfigureAppSettingsOptions>();

Code zu Startup.cs hinzugefügt

public void ConfigureServices(IServiceCollection services)
{
  // configure strongly typed settings objects
  var appSettingsSection = Configuration.GetSection("AppSettings");
  services.Configure<AppSettings>(appSettingsSection);
  services.AddScoped(sp => sp.GetService<IOptionsSnapshot<AppSettings>>().Value);                                    
  services.AddSingleton<IPostConfigureOptions<AppSettings>, ConfigureAppSettingsOptions>();            
  //next
  services.AddControllersWithViews();
}

Um auf die Konfiguration zuzugreifen, reicht es aus, AppSettings einfach vom Controller zu injizieren . HomeController.cs-



Datei :

public class HomeController : Controller
{
  private readonly ILogger<HomeController> _logger;
  private readonly AppSettings _appSettings;
  public HomeController(ILogger<HomeController> logger, AppSettings appSettings)
    {
      _logger = logger;
      _appSettings = appSettings;
    }

Lassen Sie uns Index.cshtml ändern , um den Value- Parameter des lientConfig- Objekts anzuzeigen

@model AppSettings
@{
    ViewData["Title"] = "Home Page";
}
<div class="text-center">
    <h1>   ASP.NET Core</h1>
    <h4>    ( IOptions)</h4>
</div>
<div>
    <p>
         ClientConfig,  
         = @Model.clientConfig.Value
    </p>
</div>

Starten







wir die Anwendung: Wenn Sie während des Betriebs der Anwendung den Parameter Parameter1 in „NEU !!! Parameter1 ABC "und Parameter2 bis" NEU !!! Parameter2 ABC ". Wenn Sie das nächste Mal auf die Startseite zugreifen, wird die neue Value- Eigenschaft angezeigt :

Ergebnis

Mit diesem Ansatz können Sie alle Konfigurationswerte deserialisieren, ohne die Parameter manuell durchlaufen zu müssen. Jede http-Anforderung arbeitet mit einer eigenen Instanz von AppSettings und lientConfig, wodurch die Situation von Kollisionen beseitigt wird. IPostConfigureOptions stellt sicher, dass es zuletzt ausgeführt wird, wenn alle Optionen erneut gelesen wurden. Der Nachteil dieser Lösung ist die ständige Erstellung einer Instanz der ClientConfig für jede Anforderung, was deshalb unpraktisch ist Tatsächlich sollte die ClientConfig erst nach Konfigurationsänderungen neu erstellt werden.

Deserialisierung der Konfiguration mit Validierung (ohne Verwendung von IOptions)

GitHub: Der ConfigurationTemplate_4-



Verwendungsansatz mit IPostConfigureOptions führt dazu, dass jedes Mal, wenn Sie eine Anforderung vom Client erhalten, das Objekt ClientConfig erstellt wird. Das ist nicht rational genug, weil Jede Anforderung arbeitet mit einem anfänglichen ClientConfig-Status, der sich nur ändert, wenn die Konfigurationsdatei appsettings.json geändert wird. Zu diesem Zweck verlassen wir IPostConfigureOptions und erstellen einen Konfigurationshandler, der nur aufgerufen wird, wenn sich appsettings.json ändert. Infolgedessen wird ClientConfig nur einmal erstellt, und für jede Anforderung wird eine bereits erstellte ClientConfig-Instanz angegeben.



Erstellen Sie eine SingletonAppSettings- KlasseKonfiguration (Singleton), aus der für jede Anforderung eine Instanz von Einstellungen erstellt wird. SingletonAppSettings.cs-



Datei :

public class SingletonAppSettings
{
  public AppSettings appSettings;  
  private static readonly Lazy<SingletonAppSettings> lazy = new Lazy<SingletonAppSettings>(() => new SingletonAppSettings());
  private SingletonAppSettings()
    { }
  public static SingletonAppSettings Instance => lazy.Value;
}

Kehren wir zur Startup- Klasse zurück und fügen Sie einen Verweis auf die IServiceCollection- Schnittstelle hinzu .

Es wird in der Konfigurationsbehandlungsmethode verwendet

public IServiceCollection Services { get; set; }

Lassen Sie uns ConfigureServices (IServiceCollection-Dienste) ändern und einen Verweis auf IServiceCollection übergeben . Startup.cs



Datei :

public void ConfigureServices(IServiceCollection services)
{
  Services = services;
  //  AppSettings  
  var appSettings = Configuration.GetSection("AppSettings").Get<AppSettings>();
  appSettings.ClientConfigBuild();

Erstellen Sie eine Singleton- Konfiguration und fügen Sie sie der Service-Sammlung hinzu:

SingletonAppSettings singletonAppSettings = SingletonAppSettings.Instance;
singletonAppSettings.appSettings = appSettings;
services.AddSingleton(singletonAppSettings);     

Fügen wir das AppSettings- Objekt als Gültigkeitsbereich hinzu. Bei jeder Anforderung wird eine Kopie vom Singleton erstellt:

services.AddScoped(sp => sp.GetService<SingletonAppSettings>().appSettings);

ConfigureServices (IServiceCollection-Dienste) vollständig :

public void ConfigureServices(IServiceCollection services)
{
  Services = services;
  //  AppSettings  
  var appSettings = Configuration.GetSection("AppSettings").Get<AppSettings>();
  appSettings.ClientConfigBuild();
  SingletonAppSettings singletonAppSettings = SingletonAppSettings.Instance;
  singletonAppSettings.appSettings = appSettings;
  services.AddSingleton(singletonAppSettings);             
  services.AddScoped(sp => sp.GetService<SingletonAppSettings>().appSettings);
  //next
  services.AddControllersWithViews();
}

Fügen Sie nun in Configure (IApplicationBuilder-App, IWebHostEnvironment env) einen Handler für die Konfiguration hinzu . Ein Token wird verwendet, um die Änderung in der Datei appsettings.json zu verfolgen. OnChange ist eine aufgerufene Funktion, wenn sich die Datei ändert. OnChange () - Konfigurationshandler :

ChangeToken.OnChange(() => Configuration.GetReloadToken(), onChange);

Zuerst lesen wir die Datei appsettings.json und deserialisieren die AppSettings- Klasse . Aus der Service-Sammlung erhalten wir dann einen Verweis auf den Singleton, in dem das AppSettings- Objekt gespeichert ist , und ersetzen es durch ein neues.

private void onChange()
{                        
  var newAppSettings = Configuration.GetSection("AppSettings").Get<AppSettings>();
  newAppSettings.ClientConfigBuild();
  var serviceAppSettings = Services.BuildServiceProvider().GetService<SingletonAppSettings>();
  serviceAppSettings.appSettings = newAppSettings;
  Console.WriteLine($"AppSettings has been changed! {DateTime.Now}");
}

Starten wir die Anwendung: Nachdem Sie den Startmodus als Konsolenanwendung ausgewählt haben, wird im Anwendungsfenster eine Meldung zum Auslösen des Änderungsereignisses der Konfigurationsdatei angezeigt:







Und die neuen Werte:

Ergebnis

Diese Option ist besser als die Verwendung von IPostConfigureOptions, weil Mit dieser Option können Sie ein Objekt erst nach dem Ändern der Konfigurationsdatei und nicht bei jeder Anforderung erstellen. Das Ergebnis ist eine Reduzierung der Serverantwortzeit. Nachdem das Token ausgelöst wurde, wird der Status des Tokens zurückgesetzt.

Hinzufügen von Standardeinstellungen und Überprüfen der Konfiguration

GitHub: ConfigurationTemplate_5



Wenn in den vorherigen Beispielen die Datei appsettings.json fehlt, löst die Anwendung eine Ausnahme aus. Lassen Sie uns die Konfigurationsdatei optional machen und die Standardeinstellungen hinzufügen. Wenn Sie eine Projektanwendung veröffentlichen, die aus einer Vorlage in Visula Studio erstellt wurde, befindet sich die Datei appsettings.json zusammen mit allen Binärdateien im selben Ordner, was bei der Bereitstellung in Docker unpraktisch ist. Die Datei appsettings.json wurde in die Konfiguration verschoben / :

.AddJsonFile("config/appsettings.json")

Um die Anwendung ohne appsettings.json starten zu können, ändern Sie den Parameter optiona l in true . In diesem Fall ist das Vorhandensein von appsettings.json optional. Startup.cs



Datei :

public Startup(IConfiguration configuration)
{
  var builder = new ConfigurationBuilder()
     .AddJsonFile("config/appsettings.json", optional: true, reloadOnChange: true);
  configuration = builder.Build();
  Configuration = configuration;
}

Fügen Sie der Konfigurationsdeserialisierungszeile zur öffentlichen Leere ConfigureServices (IServiceCollection-Dienste) hinzu , wenn das Fehlen der Datei appsettings.json behandelt wird:

 var appSettings = Configuration.GetSection("AppSettings").Get<AppSettings>() ?? new AppSettings();

Fügen wir eine Konfigurationsüberprüfung hinzu, die auf der IValidatableObject- Schnittstelle basiert . Wenn Konfigurationsparameter fehlen, wird der Standardwert verwendet.



Lassen Sie uns die AppSettings- Klasse von IValidatableObject erben und die Methode implementieren:

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)

AppSettings.cs- Datei :

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
  List<ValidationResult> errors = new List<ValidationResult>();
  if (string.IsNullOrWhiteSpace(this.Parameter1))
    {
      errors.Add(new ValidationResult("   Parameter1.  " +
        "   DefaultParameter1 ABC"));
      this.Parameter1 = "DefaultParameter1 ABC";
    }
    if (string.IsNullOrWhiteSpace(this.Parameter2))
    {
      errors.Add(new ValidationResult("   Parameter2.  " +
        "   DefaultParameter2 ABC"));
      this.Parameter2 = "DefaultParameter2 ABC";
    }
    return errors;
}

Fügen Sie eine Methode zum Aufrufen der Konfigurationsprüfung hinzu, die aus der Datei Startup.cs der Startup- Klasse aufgerufen

werden soll :

private void ValidateAppSettings(AppSettings appSettings)
{
  var resultsValidation = new List<ValidationResult>();
  var context = new ValidationContext(appSettings);
  if (!Validator.TryValidateObject(appSettings, context, resultsValidation, true))
    {
      resultsValidation.ForEach(
        error => Console.WriteLine($" : {error.ErrorMessage}"));
      }
    }

Fügen Sie der Konfigurationsüberprüfungsmethode in ConfigureServices (IServiceCollection-Dienste) einen Aufruf hinzu. Wenn keine Datei appsettings.json vorhanden ist, müssen Sie das AppSettings- Objekt mit Standardwerten initialisieren . Startup.cs



Datei :

var appSettings = Configuration.GetSection("AppSettings").Get<AppSettings>() ?? new AppSettings();

Parameterprüfung. Wenn der Standardwert verwendet wird, wird in der Konsole eine Meldung angezeigt, die den Parameter angibt.

 //Validate            
this.ValidateAppSettings(appSettings);            
appSettings.ClientConfigBuild();

Lassen Sie uns die Konfigurationsprüfung in onChange () ändern.

private void onChange()
{                        
  var newAppSettings = Configuration.GetSection("AppSettings").Get<AppSettings>() ?? new AppSettings();
  //Validate            
  this.ValidateAppSettings(newAppSettings);            
  newAppSettings.ClientConfigBuild();
  var serviceAppSettings = Services.BuildServiceProvider().GetService<SingletonAppSettings>();
  serviceAppSettings.appSettings = newAppSettings;
  Console.WriteLine($"AppSettings has been changed! {DateTime.Now}");
}

Wenn Sie den Schlüssel Parameter1 aus der Datei appsettings.json löschen , wird nach dem Speichern der Datei im Konsolenanwendungsfenster eine Meldung angezeigt , dass der Parameter nicht vorhanden ist:

Ergebnis

Ändern Sie den Pfad für den Standort der Konfigurationen in der Config - Ordner ist eine gute Lösung. Ermöglicht es Ihnen, nicht alle Dateien auf einem Heap zu mischen. Der Konfigurationsordner ist nur zum Speichern von Konfigurationsdateien definiert. Vereinfachte die Aufgabe der Bereitstellung und Konfiguration der Anwendung für Administratoren durch Konfigurationsüberprüfung. Wenn Sie die Ausgabe von Konfigurationsfehlern zum Protokoll hinzufügen, erhält der Administrator, wenn falsche Parameter angegeben werden, genaue Informationen über das Problem und nicht, da Programmierer kürzlich begonnen haben, auf eine Ausnahme zu schreiben: "Es ist ein Fehler aufgetreten . "



Es gibt keine ideale Option für die Arbeit mit der Konfiguration, alles hängt von der jeweiligen Aufgabe ab. Jede Option hat ihre Vor- und Nachteile.



Alle Konfigurationsvorlagen finden Sie hier .



Literatur:

1. Korrigieren Sie den ASP.NET Core
2. METANIT - Konfiguration. Konfigurationsgrundlagen
3. Singleton Design Pattern C # .net Kern
4. Konfiguration in .NET Core neu laden
5. Erneutes Laden stark typisierter Optionen bei Dateiänderungen in ASP.NET Core RC2
6. Konfiguration der ASP.NET-Kernanwendung über IOptions
7. METANIT - Übergabe der Konfiguration über IOptions
8. Konfiguration der ASP.NET-Kernanwendung über IOptions
9. METANIT - Modellselbstvalidierung