Зачем использовать app.config для хранения данных конфигурации?

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

Но я не уверен, что все это переместил в app.config и выкинул пользовательский XML файл или переместил все в другой файл и забыл о app.config.

Я вижу два аргумента: по одному для каждой опции:

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

Но я уверен, что сейчас есть намного больше, чем я могу думать. Вот почему я спрашиваю:

Каковы преимущества или недостатки использования app.config для хранения вашей конфигурации в сравнении с традиционным конфигурационным файлом?

ОТВЕТЫ

Ответ 1

Основное преимущество использования app.config заключается в том, что он является стандартным, поддерживаемым способом для приложения .NET для хранения его конфигурации. Любой, кто когда-либо использует это приложение или наследует его от вас, будет благодарен вам за использование установленных стандартов вместо "сворачивания ваших собственных".

Кроме того,.NET Framework поддерживает использование, запись, создание, изменение файла app.config - если вы идете по собственной схеме, вам придется повторно изобретать колесо много раз.

Поэтому я бы определенно рекомендовал использовать app.config - it THE способ настройки в .NET и широко распространенный и хорошо поддерживаемый стандарт.

Марк

Ответ 2

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

Например, когда разработчики работают над кодом, вы можете захотеть, чтобы приложение указывало на поле "devsql". Когда придет время QA'd, код будет развернут на промежуточном сервере, и вы хотите, чтобы приложение указывало на "stagingsql".

Если вы сохраните все конфиги в app.config, а изменения настроек были внесены в dev-версию app.config, она будет скопирована и скроена промежуточная версия - теперь ваши люди QA указывают на dev.

Сохраняя "database.xml" отдельно от "app.config", вы можете разрешать различия между различными средами, но при этом допускать, чтобы изменения в конфигурационных файлах перетекали из каждой среды в другую, не беспокоясь о перезаписи настройки.

Ответ 3

IMHO app.config - не очень удобный способ хранения данных конфигурации, в основном по двум причинам:

  • У вас нет контроля над расположением файла
  • Вы не можете определить свою собственную структуру для настройки параметров конфигурации.

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

Ответ 4

App.config имеют хорошую поддержку конфигураций соединений и протоколирования, которые вы будете использовать практически во всех приложениях. Перезапись их может принести вам много работы. Кроме того, вы можете иметь некоторую гибкость структуры, если вы используете "sectionGroup" на вашем app.config.

Но прежде чем что-то делать, я попрошу парня, который создал пользовательский файл конфигурации, почему он это сделал. Есть некоторые необычные ситуации, в которых app.config вызывает некоторые проблемы, например, если вы хотите загрузить другую DLL (с ​​собственным app.config) с помощью Assembly.Load. В этом случае вам нужно объединить две конфигурации в одном приложении app.config и молиться, чтобы у них не было никакой конфигурации с одним и тем же ключом.

В веб-тестах вы не можете перезаписывать конфигурации web.config, так что это может также вызвать некоторые проблемы, опираясь на то, что вы хотите сделать.

Но IMHO, это только в необычных ситуациях, когда app.config не будет хорошо работать. В большинстве распространенных случаев я думаю, что не стоит создавать собственную конфигурацию.

Ответ 5

Простота и удобство чтения.

App.config - это обычный метод в .NET для хранения конфигураций, поэтому его вероятные другие программисты увидели бы его. Он хранится в XML, поэтому не будет никакой производительности и файла конфигурации XML.

Он также обрабатывает местоположение, где нужно сохранить app.config(Documents and Settings/username/Local Settings/Application Data/your app/) и сохраняет конфигурации автоматически в зависимости от местоположения и версии вашего приложения, чтобы разрешить несколько версий того же приложения, чтобы сосуществовать.

Я бы сказал, что нет необходимости в BOTH app.config и пользовательском XML файле, поэтому объединение двух может быть хорошей идеей.

Ответ 6

Я согласен с тем, что XML-сериализатор в сочетании с классом "Настройки" - отличное место для хранения ваших настроек, особенно если у вас много настраиваемых типов или объектов.

Ответ 7

Очень просто создавать классы для определения собственных разделов конфигурации в Web.config, что даст вам строго типизированный доступ к вашим конфигурационным данным, позволит вам определить тип схемы для информации о конфигурации и т.д. См. экземпляр в этой статье [4guysfromrolla.com] для деталей реализации.

Ответ 8

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

Это больше проблема с веб-приложениями, в которых есть большие файлы web.config, каждый раз, когда вы делаете запрос, web.config получает синтаксический анализ, и это может стать объектом налогообложения, вы увидите это с некоторыми ORM-маркерами.