Плюсы и минусы AppSettings vs applicationSettings (.NET app.config / Web.конфиг)
при разработке приложения .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 ответов
базовый <appSettings>
легче - просто плевок в <add key="...." value="..." />
вход, и вы сделали.
недостатком является: Нет проверки типа, например, вы не можете безопасно предположить, что ваш номер, который вы хотели настроить, действительно есть номер-кто-то может поместить строку в эту настройку..... вы просто получаете доступ к нему как ConfigurationManager["(key)"]
и тогда вам решать, с чем вы имеете дело.
кроме того, со временем,<appSettings>
может получить довольно запутанный и грязный, если много части вашего приложения начинают помещать туда вещи (помните старые окна.ini-файл? :-)).
если вы можете, я бы предпочел и рекомендовал использовать ваши собственные разделы конфигурации-с .NET 2.0, это действительно стало довольно легко, таким образом, вы можете:
- a) определите свои параметры конфигурации в коде и сделайте их типобезопасными и проверил
- b) вы можете чисто отделить код настройки все Эльза. И вы можете повторно использовать свою конфигурацию код тоже!
есть ряд действительно хороших статей о вас, чтобы демистифицировать систему конфигурации .NET 2.0 на CodeProject:
высоко рекомендуется! Джон Риста проделал большую работу, объясняя систему конфигурации в .NET 2.0.
настройки приложения можно управлять из дизайнера (обычно настройками.файл настроек по умолчанию), поэтому его легче изменить, и вы можете получить к ним доступ программно через класс настроек, где они отображаются как строго типизированное свойство. Вы также можете иметь приложения и настройки пользователя, а также настройки по умолчанию для отката.
Это доступно из .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 способом, который позволяет значения по умолчанию. Если значения по умолчанию не указаны, то выводятся полезные сообщения об исключениях.
вы можете увидеть/скачать класс здесь:
понять плюсы и минусы параметры app.config
, Я предлагаю вам заглянуть в технические детали. Я включил ссылки, где вы можете найти исходный код для обработки, описывая более технические детали ниже.
позвольте мне кратко суммировать то, что я узнал, когда я работал с ними (Примечание: то же самое относится к web.config
файл веб-сайта / web применение):
applicationsettings-это
(нажмите выше, чтобы просмотреть исходный код и технические детали)
плюсы
Они позволяют хранить типизированные данные, включая типы объектов (через
serializeAs
собственность)Они имеют область пользователя и приложения, что позволяет хранить значения по умолчанию
Они поддерживается в разделе конфигурации Visual Studio
длинные строки и / или данные со специальными символами очень хорошо поддерживаются (например, встроенные строки JSON, содержащие двойные кавычки)
минусы
настройки пользователя хранятся в другом месте в профиле пользователя (с таинственные пути), может быть трудно очистить
приложения параметры области доступны только для чтения во время выполнения приложения (только параметры области пользователя могут быть изменены во время выполнения)
чтение / запись кода методов, построенного конструктором параметров Visual Studio, а не напрямую предоставленного сторонними инструментами (см. ссылку выше для решения обходного пути)
параметр appsettings
(нажмите выше, чтобы просмотреть исходный код и технические подробности)
плюсы
"легковес", т. е. легкий для регуляции
доступ для чтения и записи во время выполнения приложения
Они могут быть легко отредактированы администраторами в
Internet Information Services (IIS) Manager
(особенности просмотра - > Настройки Приложения, обратите внимание, что имя значка вводит в заблуждение, так как он может обрабатывать только AppSettings, а не ApplicationSettings)
минусы
поддержка только строковых данных; длина строки и специальные символы ограничены
у них нет пользовательской области
Они не поддерживают значения по умолчанию
не поддерживаются напрямую в конфигурации Visual Studio раздел