Vor- und Nachteile von AppSettings gegenüber applicationSettings (.NET app.config / Web.config)

Bei der Entwicklung einer .NET Windows Forms-Anwendung haben wir die Wahl zwischen diesen App.configTags, um unsere Konfigurationswerte zu speichern. Welches ist besser?

<configuration>

  <!-- Choice 1 -->
  <appSettings>
    <add key="RequestTimeoutInMilliseconds" value="10000"/>
  </appSettings>

  <!-- Choice 2 -->
  <configSections>
    <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" >
        <section name="Project1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5612342342" requirePermission="false" />
    </sectionGroup>
  </configSections>
  <applicationSettings>
    <Project1.Properties.Settings>
      <setting name="TABLEA" serializeAs="String">
        <value>TABLEA</value>
      </setting>
    </Project1.Properties.Settings>
  </applicationSettings>

</configuration>

Das Grundlegende <appSettings>ist einfacher zu handhaben - geben Sie einfach einen <add key="...." value="..." />Eintrag ein und Sie sind fertig.

Der Nachteil ist: Es gibt keine Typprüfung, z. B. können Sie nicht sicher annehmen, dass Ihre Nummer, die Sie konfigurieren möchten, wirklich eine Nummer ist - jemand könnte eine Zeichenfolge in diese Einstellung einfügen ..... Sie greifen einfach darauf zu ConfigurationManager["(key)"]und dann ist es vorbei zu Ihnen zu wissen, womit Sie es zu tun haben.

Auch im Laufe der Zeit die <appSettings> ziemlich verworren und chaotisch werden, wenn viele Teile Ihrer App Inhalte einfügen (erinnern Sie sich an die alte Datei windows.ini? :-)).

Wenn Sie können, würde ich die Verwendung Ihrer eigenen Konfigurationsabschnitte bevorzugen und empfehlen - mit .NET 2.0 ist es wirklich ganz einfach geworden. Auf diese Weise können Sie:

• a) Definieren Sie Ihre Konfigurationseinstellungen im Code und lassen Sie sie typsicher und überprüfen
• b) Sie können IHRE Einstellungen sauber von denen aller anderen trennen . Und Sie können Ihren Konfigurationscode auch wiederverwenden!

Es gibt eine Reihe wirklich guter Artikel über Sie, um das .NET 2.0-Konfigurationssystem auf CodeProject zu entmystifizieren:

1. Entdecken Sie die Geheimnisse der .NET 2.0-Konfiguration

2. Entschlüsseln der Geheimnisse der .NET 2.0-Konfiguration

3. Die Geheimnisse der .NET 2.0-Konfiguration lüften

Sehr empfehlenswert! Jon Rista hat das Konfigurationssystem in .NET 2.0 hervorragend erklärt.

Anwendungseinstellungen können von einem Designer aus gesteuert werden (normalerweise gibt es standardmäßig eine Settings.settings-Datei), sodass sie einfacher geändert werden können und Sie programmgesteuert über die Settings-Klasse darauf zugreifen können, wo sie wie eine stark typisierte Eigenschaft angezeigt werden. Sie können auch Einstellungen auf Anwendungs- und Benutzerebene sowie Standardeinstellungen für das Rollback festlegen.

Dies ist ab .NET 2.0 verfügbar und veraltet die andere Vorgehensweise (soweit ich das beurteilen kann).

Weitere Informationen finden Sie unter : msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Ich habe ein Muster verwendet, das ich vor einiger Zeit gefunden habe, in dem Sie grundlegende XML-Tags verwenden, die Einstellungen jedoch in eine statische Konfigurationsklasse einschließen. Also - eine DIY App. Einstellungen.

Statisches Konfigurationsmuster von DotNetPearls

Wenn Sie es so machen, können Sie:

• Verwenden Sie verschiedene Sätze von Konfigurationswerten für verschiedene Umgebungen (dev, test, prod).
• Sorgen Sie für sinnvolle Standardeinstellungen für jede Einstellung
• Steuern Sie, wie Werte definiert und instanziiert werden

Das Einrichten ist mühsam, funktioniert aber gut, verbirgt Verweise auf Schlüsselnamen und ist stark typisiert. Diese Art von Muster funktioniert gut für Konfigurationen, die von der Anwendung nicht geändert werden, obwohl Sie wahrscheinlich auch zur Unterstützung von Änderungen arbeiten könnten.

Konfiguration:

<add key="machineName" value="Prod" />
<add key="anotherMachineName" value="Test" />
<add key="EnvTypeDefault" value="Dev" />

<add key="RootURLProd" value="http://domain.com/app/" />
<add key="RootURLTest" value="http://test.domain.com/app/" />
<add key="RootURLDev" value="http://localhost/app/" />

<add key="HumanReadableEnvTypeProd" value="" />
<add key="HumanReadableEnvTypeTest" value="Test Mode" />
<add key="HumanReadableEnvTypeDev" value="Development Mode" />

Konfigurationsklasse:

using System;
using System.Collections.Generic;
using System.Web;
using WebConfig = System.Web.Configuration.WebConfigurationManager;

    public static class Config
    {
        #region Properties

        public static string EnvironmentType { get; private set; }

        public static Uri RootURL { get; private set; }

        public static string HumanReadableEnvType { get; private set; }

        #endregion

        #region CTOR

        /// <summary>
        /// Initializes all settings when the app spins up
        /// </summary>
        static Config()
        {
            // Init all settings here to prevent repeated NameValueCollection lookups
            // Can increase performance on high volume apps

            EnvironmentType =
                WebConfig.AppSettings[System.Environment.MachineName] ??
                "Dev";

            RootURL =
                new Uri(WebConfig.AppSettings["RootURL" + EnvironmentType]);

            HumanReadableEnvType =
                WebConfig.AppSettings["HumanReadableEnvType" + Config.EnvironmentType] ??
                string.Empty;
        }

        #endregion
    }

Um die Vor- und Nachteile der Einstellungen in der zu verstehen app.config, schlage ich vor, dass Sie sich die technischen Details beider ansehen. Ich habe Links eingefügt, über die Sie Quellcode für die Handhabung finden können. Weitere technische Details finden Sie weiter unten.

Lassen Sie mich kurz zusammenfassen, was ich bei der Arbeit mit ihnen erkannt habe ( Hinweis: Gleiches gilt für die web.configDatei einer Website / Webanwendung):

applicationSettings in .NET
(Klicken Sie oben, um den Quellcode und technische Details anzuzeigen.)

Vorteile

• Sie ermöglichen das Speichern typisierter Daten, einschließlich Objekttypen (über die serializeAsEigenschaft).

• Sie haben einen Benutzer- und Anwendungsbereich, in dem Standardwerte gespeichert werden können

• Sie werden im Konfigurationsabschnitt von Visual Studio unterstützt

• Lange Zeichenfolgen und / oder Daten mit Sonderzeichen werden sehr gut unterstützt (z. B. eingebettete JSON-Zeichenfolgen mit doppelten Anführungszeichen).

Nachteile

• Benutzereinstellungen werden an einer anderen Stelle im Benutzerprofil gespeichert (mit einem kryptischen Pfad). Die Bereinigung kann schwierig sein

• Die Einstellungen für den Anwendungsbereich sind zur Laufzeit der Anwendung schreibgeschützt (nur die Einstellungen für den Benutzerbereich können zur Laufzeit geändert werden).

• Code für Lese- / Schreibmethoden, der vom Einstellungsdesigner von Visual Studio erstellt wurde und nicht direkt von Tools von Drittanbietern bereitgestellt wird (eine Problemumgehungslösung finden Sie unter dem obigen Link).

AppSettings in .NET
Update: AppSettings in .NET Core
(Klicken Sie oben, um den Quellcode und technische Details anzuzeigen)

Vorteile

• Sind "leicht", dh einfach zu handhaben

• Lese- und Schreibzugriff zur Laufzeit der Anwendung

• Sie können von Administratoren im
  IIS-Manager ⁽ Internet Information Services) problemlos bearbeitet werden
  ^{(Funktionsansicht -> Anwendungseinstellungen. Beachten Sie, dass der Name des Symbols irreführend ist, da nur AppSettings und keine ApplicationSettings verarbeitet werden können.)}

Nachteile

• Unterstützt nur Zeichenfolgendaten; Zeichenfolgenlänge und Sonderzeichen sind begrenzt

• Sie haben keinen Benutzerbereich

• Sie unterstützen keine Standardwerte

• Werden im Konfigurationsabschnitt von Visual Studio nicht direkt unterstützt

Ich arbeite gerne mit der einfacheren Version zum Speichern und Zugreifen auf einzelne Werte.

<appSettings>
    <add key="MyConfigKey" value="true"/>
</appSettings>

Ich habe eine Utility-Klasse geschrieben, um typsicher auf Werte zuzugreifen, die Standardwerte zulässt. Wenn keine Standardeinstellungen angegeben sind, werden hilfreiche Ausnahmemeldungen angezeigt.

Sie können die Klasse hier sehen / herunterladen:

http://www.drewnoakes.com/code/util/app-settings-util/