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

Ответ 1

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

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

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

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

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

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

• Разгадка загадок конфигурации .NET 2.0

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

• Разрушение тайн конфигурации .NET 2.0

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

Ответ 2

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

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

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

Ответ 3

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

Шаблон статической конфигурации 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
    }

Ответ 4

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

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

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

Вы можете посмотреть/скачать класс здесь:

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

Ответ 5

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

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

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

Pros

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

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

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

Против

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

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

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

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

Pros

• Являются "легкими", то есть легко обрабатываются

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

• Они могут быть легко отредактированы Администраторами в
  Диспетчер служб IIS
  ^{(Обзор функций → Настройки приложения, обратите внимание, что имя значка вводит в заблуждение, поскольку оно может обрабатывать только AppSettings, а не ApplicationSettings)}

Против

• Поддержка только строковых данных

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

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

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