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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Марк

Answer 2

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

Простота и удобочитаемость программы.

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

Он также обрабатывает расположение файла app.config (Документы и настройки / имя пользователя / Локальные настройки / Данные приложения / ваше приложение /) и автоматически сохраняет настройки местоположение и версия вашего приложения, чтобы разрешить сосуществование нескольких версий одного и того же приложения.

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