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

166

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>
Jader Dias
źródło
W przykładowym kodzie MS używają appSettings msdn.microsoft.com/en-us/library/… to wydaje mi się mylące :(
Hunt
Znaleziono ten artykuł codeproject.com/KB/files/ ... wygląda na to, że appSettings są dla w / r, a applicationSettings są tylko do odczytu.
Hunt
Kolejny artykuł, który dotyczy stackoverflow.com/questions/453161/ ...
Hunt
Zauważ, że to samo dotyczy pliku web.config, więc dodałem tag web.config do tego pytania.
Matt

Odpowiedzi:

151

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.

marc_s
źródło
2
Uważam, że applicationSettings łatwiej jest dodawać, edytować i usuwać ustawienia, a ponadto nie musisz pisać linii kodu, a ponadto są one bezpieczne pod względem typu, a ponadto można je ustawić na użytkownika lub aplikację, ponieważ możesz po prostu użyć karty Ustawienia w swoim projekcie nieruchomości w VS.
markmnl
20

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

Peter C.
źródło
14

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
    }
HAL9000
źródło
11

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


Matt
źródło
9

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/

Drew Noakes
źródło
3
+1, jest to prostsze, zwłaszcza jeśli masz wiele zespołów (ustawienia zazwyczaj obejmują sekcję na zespół). Mam podobną klasę pomocników. BTW twoja klasa obecnie oczekuje, że plik konfiguracyjny będzie używał ciągów zależnych od kultury, co nie jest dobre - np. Powinno być „Double.TryParse (s, NumberStyles.Any, CultureInfo.InvariantCulture, out result)” zamiast „Double.TryParse ( s, wynik wyjściowy) ”. Również dla szczypta, wytyczne dotyczące kodowania MS zalecają GetInt32, GetInt16, GetBoolean zamiast GetInt, GetShort, GetBool.
Joe
To dobrze, ale nie odpowiada na pytanie o zalety i wady AppSettings.
Matt,
@Matt, pro jest taki, że jest prostszy. Wadą jest to, że jest prostsze. Jeśli potrzebujesz tylko kilku wartości dosłownych (bools, ints, string itp.), To podejście to daje największe korzyści. Jeśli potrzebujesz ustrukturyzowanych danych, separacji przestrzeni nazw, walidacji / uzupełniania z obsługą XSD itp., Wówczas lepiej dopasować może sekcja niestandardowa. Inną opcją jest App.configcałkowite zignorowanie pliku i użycie własnego pliku konfiguracyjnego. Robi to wiele bibliotek. Na myśl przychodzi NLog.
Drew Noakes
@DrewNoakes - Zgadzam się z tobą. Dziękuję za wyjaśnienie.
Matt,