Плюсы и минусы AppSettings против applicationSettings (.NET app.config / Web.config) - PullRequest
158 голосов
/ 20 января 2009

При разработке приложения .NET Windows Forms у нас есть выбор между этими 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>

Ответы [ 5 ]

144 голосов
/ 28 января 2009

С базовым <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.

20 голосов
/ 20 января 2009

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

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

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

14 голосов
/ 09 марта 2011

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

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

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

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

Посмотреть / скачать класс можно здесь:

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

8 голосов
/ 05 декабря 2016

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

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


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

За

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

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

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

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


Против

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

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

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


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

Плюсы

  • "легковесны", т. Е. Просты в обращении

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

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


Против

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

  • Они не имеют пользовательской области действия

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

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


...