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

Очень часто я вижу ответ на вопрос: "Как мне хранить настройки в своем приложении .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:

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

_____ СЕКЦИЯ ОБСЛУЖИВАНИЯ

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

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

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

3) POCO - простой старый объект С#, если кто-то пропустил последние несколько лет. Во всяком случае, поскольку настройки конфигурации являются декоративными и объявляются через атрибуты, ваши настройки конфигурации могут быть легко протестированы, потому что вам просто нужно отделить новый MyConfigSection() и установить свойства и т.д., Если это необходимо. Поскольку я понимаю свойства, у вас должен быть файл конфигурации с правильным xml в нем или вы sol. Другим преимуществом является то, что настраиваемые разделы конфигурации работают со всеми другими аккуратными материалами, которые вы можете делать с POCOs, такими как интерфейсы и инъекции зависимостей.

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

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

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

Ответ 3

Без обсуждения ответ будет следующим:

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

Ответ 4

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

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

Здесь подход "настроек" побеждает руками.

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

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

Ответ 5

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

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

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

Update:

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

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

Ответ 6

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

EDIT: как обсуждалось с человеком, который задал вопрос, этот ответ неверен, поскольку вопрос касается двух разных способов сохранения файла настроек. Когда я дал свой ответ, я подумал, что он имеет в виду два разных файла. О единственном другом ответе, которое я могу предоставить, это то, что это вопрос личных предпочтений.

Ответ 7

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

Win XP: c:\Documents and Settings\%Имя пользователя\Локальные настройки\Данные приложения {Имя издателя}\

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

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