Плюсы и минусы AppSettings vs applicationSettings (.NET app.config / Web.конфиг)

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

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

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

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

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
    }

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

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

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

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

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

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

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

applicationsettings-это
(нажмите выше, чтобы просмотреть исходный код и технические детали)

плюсы

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

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

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

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

минусы

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

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

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

параметр appsettings
(нажмите выше, чтобы просмотреть исходный код и технические подробности)

плюсы

• "легковес", т. е. легкий для регуляции

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

• Они могут быть легко отредактированы администраторами в
  Internet Information Services (IIS) Manager
  ^{(особенности просмотра - > Настройки Приложения, обратите внимание, что имя значка вводит в заблуждение, так как он может обрабатывать только AppSettings, а не ApplicationSettings)}

минусы

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

• у них нет пользовательской области

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

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