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

Question

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

При разработке приложения.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>

174

.net web-config app-config

Источник

user48465 20 янв '09 в 11:38

6 ответов

Решение

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

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

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

20

Источник

user1952 20 янв '09 в 13:42

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

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

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

Pros

Они позволяют хранить типизированные данные, включая типы объектов (через serializeAs имущество)
У них есть область действия пользователя и приложения, позволяющая хранить значения по умолчанию
Они поддерживаются в разделе конфигурации Visual Studio
Длинные строки и / или данные со специальными символами очень хорошо поддерживаются (например, встроенные строки JSON, содержащие двойные кавычки)

Cons

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

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

Pros

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

Cons

Поддержка только строковых данных; Длина строки и специальные символы ограничены
У них нет области действия пользователя
Они не поддерживают значения по умолчанию
Непосредственно не поддерживаются в разделе конфигурации Visual Studio

16

Источник

user1016343 05 дек '16 в 09:29

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

13

Источник

user128506 08 мар '11 в 22:01

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

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

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

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

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

9

Источник

user24874 08 июн '09 в 06:52

Одним из больших преимуществ использования ApplicationSettings является развертывание приложения с помощью ClickOnce, как подробно описано на этой странице.

Обычно, если параметр имеет тип User и был изменен со значения по умолчанию, он будет изменяться от обновления к обновлению. Если параметр имеет тип Application, он будет автоматически переопределен при обновлении приложения.

Кроме того, в VB.NET к ApplicationSettings можно получить доступ, просто используя My.Settings. что делает его простейшим вариантом настроек, доступным с точки зрения графического интерфейса пользователя.

3

Источник

user955444 15 фев '21 в 23:26

Другие вопросы по тегам .net web-config app-config

user13302 28 янв '09 в 06:31 2009-01-28 06:31 · Accepted Answer · 2009-01-28 06:31

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

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

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

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

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

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

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