Plusy i minusy AppSettings vs applicationSettings (.NET app.config / Web.config)

Podczas opracowywania aplikacji .NET Windows Forms mamy wybór między tymi App.configtagami do przechowywania naszych wartości konfiguracyjnych. Który jest lepszy?

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

Z podstawowymi <appSettings>łatwiej sobie poradzić - po prostu włóż <add key="...." value="..." />wpis i gotowe.

Wadą jest to, że nie ma sprawdzania typu, np. Nie można bezpiecznie założyć, że numer, który chciałeś skonfigurować, naprawdę istnieje - ktoś mógłby wstawić ciąg znaków do tego ustawienia ..... po prostu uzyskujesz do niego dostęp jako, ConfigurationManager["(key)"]a potem jest gotowe żebyś wiedział, z czym masz do czynienia.

Ponadto, z biegiem czasu, <appSettings>może stać się raczej zagmatwany i niechlujny, jeśli wiele części aplikacji zacznie tam umieszczać rzeczy (pamiętasz stary plik windows.ini? :-)).

Jeśli możesz, wolałbym i polecam korzystanie z własnych sekcji konfiguracyjnych - dzięki .NET 2.0 staje się to całkiem proste, w ten sposób możesz:

• a) Zdefiniuj ustawienia konfiguracyjne w kodzie i zadbaj o to, aby były bezpieczne dla typów i sprawdzone
• b) Możesz wyraźnie oddzielić SWOJE ustawienia od wszystkich innych. Możesz także ponownie wykorzystać swój kod konfiguracyjny!

Jest seria naprawdę dobrych artykułów na temat demistyfikacji systemu konfiguracji .NET 2.0 w CodeProject:

1. Rozwikłanie tajemnic konfiguracji .NET 2.0

2. Dekodowanie tajemnic konfiguracji .NET 2.0

3. Odkrywanie tajemnic konfiguracji .NET 2.0

Wysoce rekomendowane! Jon Rista wykonał świetną robotę, wyjaśniając system konfiguracji w .NET 2.0.

Ustawieniami aplikacji można sterować z poziomu projektanta (zazwyczaj jest to plik Settings.settings), więc łatwiej jest go modyfikować i można uzyskać do nich dostęp programowo za pośrednictwem klasy Settings, w której wyglądają jak silnie wpisana właściwość. Możesz także mieć ustawienia na poziomie aplikacji i użytkownika, a także domyślne ustawienia przywracania.

Jest to dostępne od .NET 2.0 i nowszych, ale jest przestarzałe w inny sposób (o ile wiem).

Więcej szczegółów można znaleźć pod adresem: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Używałem wzorca, który znalazłem jakiś czas temu, w którym używasz podstawowych tagów xml, ale zawijasz ustawienia w statyczną klasę konfiguracyjną. A więc - ustawienia aplikacji DIY.

Wzorzec konfiguracji statycznej DotNetPearls

Jeśli zrobisz to w ten sposób, możesz:

• używaj różnych zestawów wartości konfiguracyjnych dla różnych środowisk (programowanie, testowanie, produkcja)
• zapewnić rozsądne wartości domyślne dla każdego ustawienia
• kontrolować sposób definiowania i tworzenia instancji wartości

Konfiguracja jest żmudna, ale działa dobrze, ukrywa odniesienia do nazw kluczy i jest silnie wpisana. Ten rodzaj wzorca działa dobrze w przypadku konfiguracji, która nie jest zmieniana przez aplikację, chociaż prawdopodobnie możesz również wspierać zmiany.

Konfiguracja:

<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" />

Klasa konfiguracji:

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
    }

Aby zrozumieć zalety i wady ustawień w programie app.config, sugeruję przyjrzenie się szczegółom technicznym obu. Dołączyłem linki, w których można znaleźć kod źródłowy do obsługi, opisując więcej szczegółów technicznych poniżej.

Pozwólcie, że krótko podsumuję to, co rozpoznałem podczas pracy z nimi ( uwaga: to samo dotyczy web.configpliku strony internetowej / aplikacji internetowej):

ApplicationSettings w .NET
(kliknij powyżej, aby wyświetlić kod źródłowy i szczegóły techniczne)

Plusy

• Pozwalają na przechowywanie wpisanych danych, w tym typów obiektów (poprzez serializeAswłaściwość)

• Mają zakres użytkownika i aplikacji, pozwalający na przechowywanie wartości domyślnych

• Są obsługiwane w sekcji konfiguracji programu Visual Studio

• Długie ciągi i / lub dane ze znakami specjalnymi są bardzo dobrze obsługiwane (na przykład osadzone ciągi JSON zawierające podwójne cudzysłowy)

Cons

• Ustawienia użytkownika są przechowywane w innym miejscu w profilu użytkownika (z tajemniczą ścieżką), co może być trudne do wyczyszczenia

• Ustawienia zakresu aplikacji są tylko do odczytu w czasie wykonywania aplikacji (tylko ustawienia zakresu użytkownika można zmieniać w czasie wykonywania)

• Kod metod odczytu / zapisu zbudowany przez projektanta ustawień programu Visual Studio, który nie jest dostarczany bezpośrednio przez narzędzia innych firm (zobacz łącze powyżej, aby zapoznać się z rozwiązaniem obejścia)

AppSettings w .NET
Update: AppSettings w .NET Core
(kliknij powyżej, aby wyświetlić kod źródłowy i szczegóły techniczne)

Plusy

• Są „lekkie”, czyli łatwe w obsłudze

• Dostęp do odczytu i zapisu w czasie działania aplikacji

• Administratorzy mogą je łatwo edytować w
  Menedżerze Internetowych usług informacyjnych (IIS)
  ^{(Widok funkcji -> Ustawienia aplikacji, zwróć uwagę, że nazwa ikony jest myląca, ponieważ obsługuje tylko ustawienia aplikacji, a nie ustawienia aplikacji)}

Cons

• Obsługuje tylko dane ciągów; długość łańcucha i znaki specjalne są ograniczone

• Nie mają zakresu użytkownika

• Nie obsługują wartości domyślnych

• Nie są obsługiwane bezpośrednio w sekcji konfiguracji programu Visual Studio

Lubię pracować z prostszą wersją do przechowywania i uzyskiwania dostępu do pojedynczych wartości.

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

Napisałem klasę narzędziową, aby uzyskać dostęp do wartości w bezpieczny sposób, który pozwala na wartości domyślne. Jeśli nie podano wartości domyślnych, wyświetlane są pomocne komunikaty o wyjątkach.

Możesz zobaczyć / pobrać zajęcia tutaj:

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