Анатомия приложений ASP.NET

Конфигурация приложений

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

Поэтому очень часто такие значения выносят за рамки исходного кода программы и сохраняют их во внешнем файле, который впоследствии можно изменить – файл конфигурации.

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

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

Платформа .NET Framework решает этот вопрос – в рамках платформы существует стандартный способ хранения конфигурации. В качестве формата для хранения настроек используется формат XML. Использование XML в качестве формата файла конфигурации обладает рядом преимуществ:

• он имеет иерархическую структуру, что, несомненно, удобно для хранения настроек приложения;
• файл XML, по сути, является текстовым файлом, что означает, что настраивать приложения .NET можно используя любой текстовой редактор.

Все конфигурационные файлы в рамках платформы .NET имеют расширение ".config". Например, для настройки веб-приложений используются файлы "web.config", а для настольных – "app.config".

Существует целая иерархия файлов конфигурации. Схема хранения файлов настроек показана ниже.

увеличить изображение

Система конфигурации .NET Framework разделена на две части – глобальные настройки и настройки приложения. Настройки, заданные в глобальных файлах конфигурации доступны для каждого приложения, т.е. глобальные настройки наследуются в каждом приложении. На уровне приложения определяется главный файл конфигурации (он расположен в корневой папке приложения), в котором задаются основные настройки приложения. Для каждой подпапки в рамках проекта может быть определен собственный файл конфигурации. В этом случае для этой подпапки существует собственная конфигурация, которая наследуется из основного файла конфигурации и уточняется файлом конфигурации в данной папке. Такая иерархия позволяет определить глобальные настройки и постепенно, где это необходимо, уточнять их.

Глобальные файлы настроек расположены в папке "C:\Windows\Microsoft.NET\Framework\*версия+\CONFIG". Как видно из приведенной выше схемы в этой папке содержаться два файла – machine.config и web.config. Оба этих файла содержат конфигурационные настройки и имеют идентичный формат. Разница этих файлов заключается в том, что параметры, определенные в файле "machine.config" нельзя переопределить на уровне приложения, а параметры, определенные в файле "web.config" можно переопределять на любом уровне иерархии. Например, давайте рассмотрим параметр, который отвечает за конкурентный доступ к веб-сервисам на основе платформы WCF. Если этот параметр определить в глобальном файле "web.config", то он будет доступен для каждого приложения. При этом нет необходимости определять его для каждого приложения – он уже определен. Однако, если требуется изменить этот параметр для конкретного приложения, то это можно легко сделать переопределив этот параметр в файле "web.config" для приложения. Однако, если переместить определение этого параметра из глобального файла "web.config" в глобальный файл "machine.config", то переопределить параметр на уровне приложения уже будет нельзя.

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

Как уже было сказано ранее, конфигурационные файлы построены на базе формата XML. Пример конфигурационного файла приведен ниже.

Как видно, файл конфигурации содержит ряд настроек в иерархическом виде. Каждый узел в файле настроек определяет отдельный аспект функционирования веб-приложения – настройки кеширования, настройки компиляции и отладки, строки соединения с СУБД, параметры безопасности и т.д. Для каждого узла определен собственный класс-обработчик этих настроек. Узел не может быть добавлен в конфигурационный файл, если с ним не ассоциирован никакой класс-обработчик. В противном случае при запуске приложения будет сгенерирована ошибка.

Система конфигурации .NET Framework предполагает использование файлов конфигурации и для хранения собственных параметров конфигурации приложения, а не только общих настроек. Для того, чтобы добавить свою секцию конфигурации в файл настроек, для начала следует определить эту секцию специальным образом. Для этого существует стандартная секция "configSections". Определить секцию конфигурации можно следующим образом.

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

Количество параметров, уровень вложенности и весь внешний вид секции конфигурации определяет класс-обработчик для этой конфигурационной секции. Этот класс является наследником базового класса "ConfigurationSection", который содержит базовые механизмы для работы с данными конфигурационных файлов. В наиболее простой ситуации можно определить обработку свойств секции, в данном случае свойства "MyParam1". Для этого необходимо создать в классе-обработчике новое публичное свойство и разметить его соответствующим атрибутом "ConfigurationProperty".

Такое определение позволит среде исполнения .NET Framework корректно интерпретировать конфигурационную секцию.

Следует отметить, что все конфигурационные секции, доступные по умолчанию в .NET Framework объявлены подобным образом (используя секцию "configSections"). Эти определения сделаны в глобальном файле "machine.config".

увеличить изображение

Наконец, для получения доступа к существующим конфигурационным секциям используется объект WebConfigurationManager. Для этого следует воспользоваться статическим методом "OpenWebConfiguration" для получения объекта Configuration, а затем методом "GetSection" для получения доступа к конкретной секции. После этого, эту секцию можно привести к классу-обработчику этой секции и, используя публичные свойства последнего, работать с настройками конфигурации.

Таким образом, подсистема конфигурации .NET Framework является мощным механизмом, который позволяет, как переопределять стандартные настройки приложения, так и определять собственные параметры конфигурирования.

Краткие итоги

Типичная проблема при разработке любого приложения – способ хранения параметров приложения. В .NET Framework существует стандартный механизм, который позволяет решить эту проблему. Все конфигурационные файлы приложения хранятся в формате XML и имеют расширение ".config". При этом существует иерархия файлов конфигурации. На глобальном уровне существует два файла – machine.config и web.config. Настройки, определенные в файле machine.config нельзя переопределять на уровне приложения, а настройки, определенные в файле web.config – можно. На уровне приложения файлы конфигурации также могут наследоваться. Для создания собственной секции настройки необходимо создать класс-обработчик для этой секции и объявить секцию в разделе "configSections". Доступ к настройкам приложения осуществляется на основе объекта WebConfigurationManager.