Плюсы и минусы AppSettings против applicationSettings (.NET app.config / Web.config)

При разработке .NET Windows Forms Application у нас есть выбор между этими App.configтегами для хранения наших значений конфигурации. Какой лучше?

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

С основным <appSettings>легче разобраться - просто нажмите на <add key="...." value="..." />запись, и все готово.

Недостатком является то, что здесь нет проверки типов, например, вы не можете с уверенностью предположить, что ваш номер, который вы хотите настроить, действительно есть число - кто-то может вставить строку в этот параметр ..... вы просто получаете к нему доступ, а ConfigurationManager["(key)"]затем он работает чтобы вы знали, с чем имеете дело.

Кроме того, со временем, это <appSettings>может стать довольно запутанным и грязным, если многие части вашего приложения начнут помещать туда вещи (помните старый файл windows.ini? :-)).

Если вы можете, я бы предпочел и порекомендовал использовать ваши собственные разделы конфигурации - с .NET 2.0 это действительно стало довольно легко. Таким образом, вы можете:

• a) Определите параметры конфигурации в коде и проверьте их тип и безопасность.
• б) Вы можете четко отделить ВАШИ настройки от всех остальных. И вы также можете повторно использовать свой конфигурационный код!

Есть серия действительно хороших статей о том, как демистифицировать систему конфигурации .NET 2.0 в CodeProject:

1. Разгадывание тайн конфигурации .NET 2.0

2. Расшифровка тайн конфигурации .NET 2.0

3. Раскрывая тайны конфигурации .NET 2.0

Настоятельно рекомендуется! Джон Риста проделал большую работу, объясняя систему конфигурации в .NET 2.0.

Настройками приложения можно управлять из конструктора (обычно это файл Settings.settings по умолчанию), поэтому его проще изменить, и вы можете получить к ним программный доступ через класс Settings, где они выглядят как строго типизированное свойство. Вы также можете иметь настройки уровня приложения и пользователя, а также настройки по умолчанию для отката.

Это доступно с .NET 2.0 и далее, и устарел другой способ сделать это (насколько я могу судить).

Более подробная информация дана по адресу: msdn.microsoft.com/en-us/library/k4s6c3a0.aspx

Я использовал шаблон, который нашел некоторое время назад, когда вы используете базовые теги xml, но оборачиваете настройки в статический класс конфигурации. Итак - сделай сам. Настройки.

Шаблон статической конфигурации DotNetPearls

Если вы делаете это таким образом, вы можете:

• использовать разные наборы значений конфигурации для разных сред (dev, test, prod)
• обеспечить разумные значения по умолчанию для каждого параметра
• контролировать, как значения определяются и создаются

Это утомительно, но хорошо работает, скрывает ссылки на ключевые имена и строго типизировано. Этот тип шаблона хорошо работает для конфигурации, которая не изменяется приложением, хотя вы, вероятно, могли бы работать и для поддержки изменений.

Config:

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

Конфиг класс:

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
    }

Чтобы понять плюсы и минусы настроек в app.config, я предлагаю вам изучить технические детали обоих. Я включил ссылки, где вы можете найти исходный код для обработки, описывая более технические детали ниже.

Позвольте мне кратко изложить то, что я узнал, когда работал с ними ( примечание: то же самое применимо к web.configфайлу веб-сайта / веб-приложения):

ApplicationSettings в .NET
(нажмите выше для просмотра исходного кода и технических деталей)

Pros

• Они позволяют хранить типизированные данные, в том числе типы объектов (через serializeAsсвойство)

• У них есть область действия пользователя и приложения, позволяющая хранить значения по умолчанию

• Они поддерживаются в разделе конфигурации Visual Studio

• Длинные строки и / или данные со специальными символами очень хорошо поддерживаются (например, встроенные строки JSON, содержащие двойные кавычки)

Cons

• Пользовательские настройки хранятся в другом месте в профиле пользователя (с загадочным путем), может быть трудно очистить

• Параметры области приложения доступны только для чтения во время выполнения приложения (только параметры области пользователя могут быть изменены во время выполнения)

• Код методов чтения / записи, созданный конструктором настроек Visual Studio, напрямую не предоставленный сторонними инструментами (см. Ссылку выше для обходного решения)

AppSettings в .NET
Update: AppSettings в .NET Core
(нажмите выше для просмотра исходного кода и технических деталей)

Pros

• «Легкие», то есть легкие в обращении

• Доступ на чтение и запись во время выполнения приложения

• Они могут быть легко отредактированы администраторами в
  Диспетчере информационных служб Интернета (IIS)
  ^{(Просмотр функций -> Параметры приложения, обратите внимание, что имя значка вводит в заблуждение, поскольку оно может обрабатывать только параметры приложения, а не параметры приложения)}

Cons

• Поддержка только строковых данных; Длина строки и специальные символы ограничены

• У них нет области действия пользователя

• Они не поддерживают значения по умолчанию

• Непосредственно не поддерживаются в разделе конфигурации Visual Studio

Мне нравится работать с более простой версией для хранения и доступа к отдельным значениям.

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

Я написал служебный класс для доступа к значениям безопасным для типов способом, который допускает значения по умолчанию. Если значения по умолчанию не предоставлены, тогда выдаются полезные сообщения об исключениях.

Вы можете увидеть / скачать класс здесь:

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