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

167

При разработке .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>
Джадер Диас
источник
В примере кода MS они используют appSettings msdn.microsoft.com/en-us/library/… это меня смущает :(
Охота
Нашел эту статью codeproject.com/KB/files/… Похоже, это подразумевает, что appSettings для w / r, а applicationSettings только для чтения.
Охота
Еще одна статья, которая имеет отношение к stackoverflow.com/questions/453161/…
Охота
Обратите внимание, что то же самое применимо к web.config, поэтому я добавил тег web.config к этому вопросу.
Мэтт

Ответы:

151

С основным <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.

marc_s
источник
2
Я считаю, что настройки приложения проще добавлять, редактировать и удалять настройки, плюс вам не нужно писать ни строки кода, и они безопасны от типа, и вы можете использовать их для пользователя или приложения, потому что вы можете просто использовать вкладку «Настройки» в своем проекте. свойства в VS.
markmnl
20

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

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

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

Питер С
источник
14

Я использовал шаблон, который нашел некоторое время назад, когда вы используете базовые теги 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
    }
HAL9000
источник
11

Чтобы понять плюсы и минусы настроек в 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


Matt
источник
9

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

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

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

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

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

Дрю Ноакс
источник
3
+1, это проще, особенно если у вас несколько сборок (в настройках обычно есть раздел для каждой сборки). У меня есть аналогичный класс помощника. Кстати, ваш класс в настоящее время ожидает, что файл конфигурации будет использовать строки, чувствительные к культуре, что не очень хорошая вещь - например, должно быть «Double.TryParse (s, NumberStyles.Any, CultureInfo.InvariantCulture, out result)», а не «Double.TryParse ( s, out result) ". Кроме того, в руководствах по кодированию MS рекомендуется использовать GetInt32, GetInt16, GetBoolean, а не GetInt, GetShort, GetBool.
Джо
Это нормально, но не отвечает на вопрос о плюсах и минусах AppSettings.
Мэтт
@ Matt, профи в том, что это проще. Мошенничество в том, что это проще. Если вам нужна только пара литеральных значений (bools, ints, string и т. Д.), Тогда этот подход дает максимальную отдачу. Если вам нужны структурированные данные, разделение пространства имен, проверка / завершение с поддержкой XSD и т. Д., То лучше подойдет пользовательский раздел. Другой вариант - полностью игнорировать App.configфайл и использовать свой собственный файл конфигурации. Множество библиотек делают это. NLog приходит на ум.
Дрю Ноакс
@DrewNoakes - я согласен с тобой. Спасибо за разъяснения.
Мэтт