Какой из этих или других методов (если есть) вы предпочитаете? Почему?
Если пары ключевых значений недостаточно, я использую разделы конфигурации, поскольку они не являются сложными для использования (если вам не нужен сложный раздел):
Определите свой раздел:
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. Единственная область конфигурации - лучший способ разместить вашу конфигурацию. Напишите gui, чтобы управлять им, и вы будете очень счастливы.
Перемещение файлов app.config на 200 клиентских ящиков. Это не забавно, особенно когда вас пропускают (и они это делают, поверьте).
В прошлом я был администратором сети/системы, и теперь я разрабатываю внутренние утилиты для приложений баз данных. Я нашел следующее:
Простые не вложенные файлы конфигурации лучше всего подходят для приложений, которые не будут меняться там, где они очень сильно обращаются к их ресурсам.
Все, что сложнее, нужно зайти в базу данных с пользовательским интерфейсом администрирования. Это относится только к обычным бизнес-пользователям. Если вас беспокоит повреждение базы данных, используйте подход к сложному конфигурационному файлу. Файлы, как правило, повреждают меньше, чем базы данных.
Теперь, если ваши пользователи - другие разработчики, у вас будет гораздо больше гибкости в том, что использовать для хранения ваших конфигураций.
Я использую настраиваемый файл конфигурации xml, где для каждой среды используется другой файл конфигурации (dev/qa/prod). Конфигурационные файлы - это шаблоны, которые динамически создаются с помощью таких функций, как конфигурации хоста и порта для служб - это упрощает работу с несколькими средами и отказоустойчиво, поскольку он может обрабатываться кодом экземпляра шаблона.
Конечно, если у вас очень мало настроек и они не связаны с несколькими средами, то app.config является более стандартным и, вероятно, лучшим способом.
Я нахожу NameValueCollectionHandler самым простым и лучшим, и я обычно связываюсь с внешним конфигурационным файлом через атрибут configSource.
Я пытаюсь установить конфигурацию ABSOLUTE MINIMUM в конфигурационных файлах, причем большинство из них настраивается в коде с помощью приложения, которое самоочевидно в своей среде развертывания (например, по имени машины или IP-адресу, если известно). Конечно, это потребовало гораздо большего предварительного планирования и знаний о вашей среде, но гораздо меньше головной боли при развертывании.
Конфигурации клавиш/значений я работают очень хорошо для файлов простых конфигураций. Это становится проблемой, когда файл начинает расти и его трудно поддерживать. Мы начали разделять конфигурационный файл на "общие" и "конкретные" конфигурации приложений. Доступ к файлам прозрачен для приложения, "общие" значения в большинстве случаев одинаковы, но "конкретные" отличаются для каждого развернутого приложения.
Я использую настраиваемый файл конфигурации xml. Каждый параметр имеет ключ, значение и тип.
В нем есть один основной раздел, содержащий все настройки и дополнительные разделы, содержащие переопределения настроек для определенных сред (dev, staging, live). Это не нужно заменять разделы файла при развертывании. У меня есть небольшая оболочка, которую вы можете вызвать, чтобы получить конкретную настройку или словарь, содержащий все из них.
Недавно я создал шаблон T4, который будет читать конфигурационный файл и создать статический строго типизированный класс настроек. Это был огромный период времени.
Я сохраняю большую часть своей конфигурации в контейнере IoC, например. Spring.Net.
Если у вас есть .NET 3.0, я нахожу XamlReader/XamlWriter очень удобным для хранения настроек. Они могут писать/читать любой объект .NET в XAML, если:
Особенно приятно, что вам не нужно украшать ваши объекты настроек любыми атрибутами.
dataset.WriteXML()/dataset.ReadXML() работает хорошо для меня, когда app.config больше не режет.
В основном я предпочитаю использовать пользовательский XML файл и метод Xml Serialization для чтения и записи этих файлов конфигурации... Не ограничиваясь парами ключ/значение и не сложно реализовать...
Мне повезло сменить собственный специальный класс, который возвращает данные конфигурации из файла ".settings", связанного с вызывающей сборкой. Файл представляет собой XML, и класс настроек предоставляет его публично как XDocument. Кроме того, индексщик для этого класса настроек возвращает значения элементов из /settings/settings.
Работает отлично для простых приложений, где вам просто нужен доступ к параметрам пары ключ/значение, и отлично подходит для сложных настроек, где вам нужно определить свою собственную структуру и использовать System.Xml.Linq для запроса XML-документа.
Еще одно преимущество вашей собственной загрузки заключается в том, что вы можете использовать FileSystemWatcher и callback Action type для автоматического запуска метода при изменении файла во время выполнения.