Почему люди постоянно рекомендуют использовать appConfig вместо файлов настроек? (.СЕТЬ)

Question

Очень часто я вижу ответ на вопрос: «Как хранить настройки в моем приложении .NET?» это отредактировать файл app.config, вручную добавив записи в app.config (или web.config) следующим образом:

<configuration> 
  <appSettings>
    **<add key="ConfigValueName" value="ABC"/>**
  </appSettings>
</configuration>

Затем, доступ к ним, как:

string configValue = Configuration.AppSettings["ConfigValueName"];

Я буду называть подход, описанный выше, как подход "app.config". Очень редко я вижу людей, которые рекомендуют добавлять файл «Настройки» в проект. Я видел это так много раз в Интернете и в stackoverflow ... Я начинаю задумываться, не пропустил ли я что-то ... потому что я не уверен, почему вы используете этот метод вместо "Настройки" " файл. Я не вошел в .NET до VS2005, поэтому у меня есть одна теория, как все было сделано в VS2003, и люди никогда не переключались?

Примеры людей, рекомендующих подход app.config:

• Самый простой способ иметь файл конфигурации в приложении Windows Forms C #
• Рекомендации: как хранить настройки в C # (Формат / Тип)?

С моей точки зрения, имеет следующие преимущества подхода "Файл настроек":

1. Может использоваться как для настроек приложения (общих для всех пользователей), так и для настроек пользователя из одного интерфейса.
2. Возможность использовать дизайнер настроек поддержки в visual studio. Меньше ошибок, чем редактирование XML-файла напрямую IMHO.
3. Рефакторинг - вы можете переименовать конкретное имя параметра, и оно автоматически обновит ссылки в вашем коде.
4. Проверка типа компиляции.
5. Поддержка автозаполнения.
6. Свойства-сетка. Я обнаружил, что элемент управления PropertyGrid - это очень простой способ создания формы быстрых параметров. Вы просто делаете propertyGrid1.SelectedObject = Settings1.Default; и все готово.

В случае, если вы не уверены, что я подразумеваю под файловым подходом «Настройки», смотрите этот пост , который является одним из немногих примеров, когда кто-то рекомендует использовать файлы настроек вместо app.confg.

РЕДАКТИРОВАТЬ: Пожалуйста, поймите: Цель этой темы - выяснить, почему люди будут использовать подход app.config, описанный выше, по сравнению с подходом файла настроек. Я столкнулся с ограничениями файлового подхода к настройкам и время от времени был вынужден использовать свое собственное решение. Это совершенно другое обсуждение .

Answer 1

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

Файлы настроек можно изменить с помощью команды Save().

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

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

Я использовал его в одном проекте и нашел гораздо более полезным создать свой собственный класс AppSettings, который использует XML-файл для настроек. У меня есть контроль над форматом и расположением файла.

Answer 2

Существует третий и гораздо лучший способ, чем AppSettings или Properties: разделы пользовательской конфигурации . Преимущества перед AppSettings:

1) Строго типизированный доступ

2) Встроенные механизмы проверки как для схемы, так и для формы.

3) На основе POCO, что делает его легко тестируемым - просто обновите свой собственный тестовый конфиг.

4) Не полагаться на магические струны. Не то чтобы вы не могли легко обернуть AppSettings в класс и получить к нему доступ таким образом, но 95% разработчиков этого не делают.

5) XML в конфигурации становится более понятным, когда вы доберетесь до дюжины или около того настроек. Также гораздо понятнее, чем биты Propterties ИМХО.

6) Не полагайтесь на визуальную студию, чтобы она работала хорошо.

Конечно, я никогда не использовал свойства, потому что сначала я получил доступ к пользовательским разделам конфигурации.

Кстати, если вы не слышали об этом, вы все еще используете их каждый день - как вы думаете, какие стандартные разделы конфигурации в файлах конфигурации .NET?

_____ РАЗДЕЛ КЛИРИФИКАЦИИ

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

1) Верно, и свойства, и пользовательские разделы конфигурации имеют строго типизированный доступ. AppSettings нет. AppSettings плохой, Props / CC хороший.

2) Когда вы загружаете раздел конфигурации, приложение выдает исключение конфигурации, если оно не предоставляет необходимую информацию или неправильную информацию. То же самое, что когда вы портите app.config или web.config. Существует немного больше инфраструктуры проверки, которую я не использовал, потому что мне нравится терпеть неудачу рано или рано или совсем нет.

3) POCO - простой старый объект C # на случай, если кто-то пропустил последние несколько лет. В любом случае, поскольку параметры конфигурации являются декоративными и объявляются с помощью атрибутов, ваши параметры конфигурации могут быть легко протестированы, поскольку вам просто нужно добавить новый MyConfigSection () и установить свойства и т. Д., В зависимости от ситуации. Как я понимаю свойства, у вас должен быть файл конфигурации с правильным XML-кодом, или вы сол. Другим преимуществом является то, что пользовательские разделы конфигурации работают со всеми другими полезными вещами, которые вы можете делать с POCO, такими как интерфейсы и внедрение зависимостей.

4) Правда, разделы «Свойства» и «Конфигурация пользователя» строго типизированы, а параметры AppSettings - нет. AppSettings плохой, Props / CC хороший.

5) Действительно нацелены на AppSettings. Я унаследовал несколько приложений с буквально 2 страницами <add name="foo" value="bar" /> в конфигурации. Это легко по сравнению с xml jibberish, который выдает свойства. С другой стороны, ваш пользовательский раздел конфигурации может быть довольно семантическим и не требующим пояснений, потому что вы объявляете имена разделов и атрибуты. Я могу довольно легко отредактировать его в блокноте на рабочем сервере, и я не буду слишком нервничать из-за того, что укрою себя ногой в крайнем случае.

Таким образом, помимо отсутствия сетки свойств на основе VS (что я бы сказал, это плохо - зачем вам сетка для редактирования конфигурации?), Пользовательские разделы конфигурации имеют много преимуществ и никаких реальных недостатков по сравнению в свойствах. Как пользовательские разделы конфигурации, так и свойства имеют огромные преимущества перед AppSettings.

Answer 3

Поскольку файловая инфраструктура настроек (1) более сложна и (2) недостаточно документирована, учитывая ее сложность.

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

Я просто ссылаюсь на эту статью, чтобы закончить. Не стесняйтесь вставлять некоторые полезные ссылки на концептуальную документацию MSDN, чтобы противоречить моему аргументу.

---

Обновление:

Мне нужно быть честным и предоставить конкретный вариант использования, который я не нашел документированным:

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

Answer 4

Два сценария:

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

Здесь подход "настройки" выигрывает руки.

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

Здесь "appSettings" может быть намного проще в управлении. При подходе «настройки» будет раздел для каждой настраиваемой сборки, который будет добавлен в файл конфигурации основного приложения.

Answer 5

Без обсуждения, тогда ответ:

"Потому что это проще."

Answer 6

Я также хотел бы отметить одно различие между app.Config и окном настроек. Если вы сохраните что-либо в разделе «Настройки», настройки будут сохранены в следующих местах.

Win XP: c: \ Documents and Settings \% Username% \ Local Settings \ Application Data {Имя издателя} \

Win 7: C: \ Users \% Имя пользователя% \ AppData \ Local {Имя издателя} \

Пока настройки app.config сохраняются только в файле конфигурации.

Answer 7

Неправильно. Отчасти проблема с подходом файла настроек заключается в том, что приложение требует, чтобы приложение находилось в определенном месте, а файл настроек - в правильном месте. Если один из них будет случайно перемещен, то настройки могут быть потеряны навсегда, как если бы они были удалены. Также может возникнуть проблема с несколькими файлами настроек с одним и тем же именем в папке, что приведет к перезаписи одного из них. Это особенно плохо, если программное обеспечение зависит от файла настроек. Эти проблемы проявляются не так сильно, как в случае с установленным программным обеспечением, но в программном обеспечении, которое не установлено, а просто загружается и запускается, это может быть серьезной проблемой. Представьте, что кто-то загрузил несколько этих программ в один и тот же каталог, и все они использовали одно и то же имя файла настроек.

РЕДАКТИРОВАТЬ: Как обсуждалось с человеком, который задал вопрос, этот ответ является неправильным, поскольку вопрос касается двух разных способов сохранения в файле настроек. Когда я давал свой ответ, я думал, что он имел в виду два разных файла. О единственном другом ответе, который я могу дать, это то, что это вопрос личных предпочтений.