Какой из этих или других методов (если есть) вам больше нравится? Почему?
Когда пар ключ-значение недостаточно, я использую разделы конфигурации, поскольку они несложны в использовании (если вам не нужен сложный раздел):
Определите свой настраиваемый раздел:
public class CustomSection : ConfigurationSection
{
[ConfigurationProperty("LastName", IsRequired = true,
DefaultValue = "TEST")]
public String LastName
{
get { return (String)base["LastName"]; }
set { base["LastName"] = value; }
}
[ConfigurationProperty("FirstName", IsRequired = true, DefaultValue =
"TEST")]
public String FirstName
{
get { return (String)base["FirstName"]; }
set { base["FirstName"] = value; }
}
public CustomSection()
{
}
}
Программно создайте свой раздел (если он еще не существует):
// Create a custom section.
static void CreateSection()
{
try
{
CustomSection customSection;
// Get the current configuration file.
System.Configuration.Configuration config = ConfigurationManager.OpenExeConfiguration(@"ConfigurationTest.exe");
// Create the section entry
// in the <configSections> and the
// related target section in <configuration>.
if (config.Sections["CustomSection"] == null)
{
customSection = new CustomSection();
config.Sections.Add("CustomSection", customSection);
customSection.SectionInformation.ForceSave = true;
config.Save(ConfigurationSaveMode.Full);
}
}
catch (ConfigurationErrorsException err)
{
//manage exception - give feedback or whatever
}
}
Следующее определение CustomSection и фактическое CustomSection будут созданы для вас:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="CustomSection" type="ConfigurationTest.CustomSection, ConfigurationTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" allowLocation="true" allowDefinition="Everywhere" allowExeDefinition="MachineToApplication" overrideModeDefault="Allow" restartOnExternalChanges="true" requirePermission="true" />
</configSections>
<CustomSection LastName="TEST" FirstName="TEST" />
</configuration>
Теперь получите свойства вашего раздела:
CustomSection section = (CustomSection)ConfigurationManager.GetSection("CustomSection");
string lastName = section.LastName;
string firstName = section.FirstName;
Если мне это сойдет с рук, я просто буду использовать App.Config, однако, если мне понадобится что-то более сложное, я буду использовать настраиваемые разделы конфигурации. Да, это сложно понять вначале, но, на мой взгляд, единый источник конфигурации и знакомая конфигурация для всех настроек стоит потраченного времени.
Поместите вашу конфигурацию в базу данных. Если вы запускаете свое приложение более чем на 1 машине (например, клиент-серверное приложение), тогда все системы конфигурации для каждой машины являются PITA. Единая область конфигурации - лучший способ разместить вашу конфигурацию. Напишите графический интерфейс для управления этим, и вы будете очень счастливы.
Развертывание файлов app.config в 200 клиентских ящиках ... это не весело, особенно когда что-то пропустили (а они это делают, поверьте мне).
Раньше я был сетевым / системным администратором, а теперь разрабатываю внутренние утилиты для приложений баз данных. Я обнаружил следующее:
Простые невложенные файлы конфигурации лучше всего подходят для приложений, которые не будут сильно менять места доступа к своим ресурсам.
Что-либо более сложное необходимо поместить в базу данных с пользовательским интерфейсом администрирования. Это относится только к обычным бизнес-пользователям. Если вы беспокоитесь о повреждении базы данных, используйте подход комплексного файла конфигурации. Файлы имеют тенденцию к повреждению меньше, чем базы данных.
Теперь, если вашими пользователями являются другие разработчики, у вас будет гораздо больше гибкости в выборе того, что использовать для хранения ваших конфигураций.
Я считаю NameValueCollectionHandler самым простым и лучшим, и Обычно я бы связался с внешним файлом конфигурации через атрибут configSource.
Я пытаюсь поместить АБСОЛЮТНУЮ МИНИМАЛЬНУЮ конфигурацию в файлы конфигурации, при этом большая часть ее настраивается в коде с Приложением, которое само знает о своей среде развертывания (например, по имени компьютера или IP-адресу, если он известен). Конечно, для этого требовалось гораздо больше предварительного планирования и знаний о вашей среде, но гораздо меньше головной боли при развертывании.
Я использую собственный файл конфигурации xml, в котором для каждой среды используется другой файл конфигурации (dev / qa / prod). Файлы конфигурации представляют собой шаблоны, которые динамически создаются с такими вещами, как конфигурации хоста / порта для служб - это упрощает работу с несколькими средами и переключение при отказе, поскольку это может быть обработано кодом создания экземпляра шаблона.
Конечно, если у вас очень небольшая конфигурация и вы не связаны с несколькими средами, тогда app.config более стандартный и, вероятно, лучший способ.
Я считаю, что конфигурации "ключ-значение" очень хорошо подходят для простых файлов конфигурации. Это становится проблемой, когда файл начинает расти и его становится трудно поддерживать. Мы начали разбивать конфигурационный файл на «общие» и «специфические» конфигурации приложений. Доступ к файлам прозрачен для приложения, «общие» значения в большинстве случаев одинаковы, но «конкретные» различаются для каждого развернутого приложения.
Я использую собственный файл конфигурации xml. У каждого параметра есть ключ, значение и тип.
В нем есть один основной раздел, содержащий все настройки, и дополнительные разделы, содержащие переопределения настроек для определенных сред (dev, staging, live). При этом мне не нужно заменять разделы файла при развертывании. У меня есть небольшая оболочка, которую вы можете вызвать, чтобы получить конкретную настройку или словарь, содержащий их все.
Недавно я создал шаблон T4, который будет читать конфигурацию файл и создайте статический строго типизированный класс настроек. Это была огромная экономия времени.
Я храню большую часть своей конфигурации в контейнере IoC, например Spring.Net.
Если у вас есть .NET 3.0, я считаю, что XamlReader / XamlWriter очень удобен для хранения настроек. Они могут записывать / читать любой объект .NET в XAML, если:
Особенно приятно, что вам не нужно украшать свои объекты настроек какими-либо атрибутами.
dataset.WriteXML () / dataset.ReadXML () у меня работает очень хорошо, когда app.config больше не сокращает его.
В основном я предпочитаю использовать собственный XML-файл и метод сериализации Xml для чтения и записи этих файлов конфигурации ... Не ограничен парами ключ / значение и не сложен в реализации ...
Мне повезло с созданием моего собственного специального класса, который возвращает данные конфигурации из файла ".settings", связанного с вызывающей сборкой. Это файл XML, и класс настроек представляет его публично как XDocument. Кроме того, индексатор для этого класса настроек возвращает значения элементов из узлов / settings / setting.
Отлично подходит для простых приложений, где вам просто нужен доступ к параметрам пары ключ / значение, и отлично подходит для сложных настроек, когда вам нужно определить свою собственную структуру и использовать System.Xml.Linq для запроса XML-документа.
Еще одно преимущество использования собственного метода заключается в том, что вы можете использовать FileSystemWatcher и callback Action type для автоматического запуска метода при изменении файла во время выполнения.
