Почему люди постоянно рекомендуют использовать 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:

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

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

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

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


.net appsettings app-config application-settings .net-2.0
person blak3r    schedule 19.06.2009    source источник
comment
Ваш заголовок, кажется, указывает на предвзятость. Вы получите лучшие ответы, если сделаете больше настроек приложения, а не свойств. Вот почему люди занимают оборонительную позицию. Некоторые люди назначают такие закрытые вопросы - так что будьте с ними осторожны :)   -  person TheSoftwareJedi    schedule 19.06.2009
comment
У меня нет предвзятости. Мне действительно любопытно, каковы преимущества, поскольку люди, кажется, используют его чаще. Спасибо за предложение. Я перефразирую.   -  person blak3r    schedule 19.06.2009

Ответы (7)


arrow_upward
23
arrow_downward

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

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

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

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

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

person Chris Thompson    schedule 19.06.2009
comment
Я бы также поддержал подход Криса, я использовал свой собственный класс настроек гораздо эффективнее, чем автоматические. - person Paul Farry; 19.06.2009
comment
@Chris Thompson: Я согласен с тем, что существует ряд проблем с использованием подхода с использованием файла настроек. Но цель этого поста - обсудить, почему люди рекомендуют вручную изменять app.config ВМЕСТО использования файлов настроек. Как я уже упоминал выше, у меня определенно есть проблемы с файлами настроек и, следовательно, почему они будут использовать свой собственный файл конфигурации. Вы коснулись одного из них. - person blak3r; 19.06.2009
comment
Хорошая точка зрения. Разве основная проблема с app.config не в том, что приложение не может изменять значения? Например, я не могу написать графический интерфейс, позволяющий пользователю настраивать свои параметры и сохранять эти параметры в app.config. Я могу сделать это с помощью подхода «Настройки». - person Chris Thompson; 20.06.2009
comment
@ChrisThompson - Полностью согласен, что проблема с файлом настроек воняет ... но все еще не объясняет, почему app.config кажется более популярным. Ну что ж. - person blak3r; 16.02.2012

arrow_upward
13
arrow_downward

Существует третий и намного лучший способ, чем 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) Верно, разделы Properties и custom config строго типизированы, а AppSettings - нет. AppSettings плохо, Props / CC - хорошо.

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

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

person Wyatt Barnett    schedule 19.06.2009
comment
Согласованный. Кому-то нужно создать код для этого, потому что первые пару раз лепить их вручную - это больно. - person TheSoftwareJedi; 19.06.2009
comment
Должно быть, здесь что-то не хватает. 1) DISAGREE Файлы настроек также строго типизированы 2) Проверка может быть выполнена с помощью файлов настроек ... Я лично никогда этого не делал, так как при использовании поддержки конструктора vs это неочевидно 3) Не совсем уверен в этом ... пожалуйста, объясните ... 4) Нет никаких волшебных строк, использующих подход с настройками 5) НЕ СОГЛАСНО - то же самое можно сделать, используя несколько файлов настроек ... каждый будет иметь свой собственный раздел 6) СОГЛАСЕН -------- ----- Итак, я не согласен с вашими преимуществами, а недостатков много ... - person blak3r; 19.06.2009
comment
См. Обновления для комментариев. @ TheSoftwareJedi - время от времени я экспериментирую с этой идеей, но она ужасно сложна, поскольку API настолько богат. Я думаю, что пользовательские фрагменты VS - это хороший способ справиться с этим сам, но я всегда забываю писать указанные фрагменты, поскольку обычно они пишутся один раз для каждого проекта. - person Wyatt Barnett; 19.06.2009
comment
Я согласен с тем, что разделы пользовательской конфигурации часто бывают полезны. Но они добавляют сложности: например, вам нужно сослаться на сборку, которая определяет их, в разделе ‹configSections› - с правильным номером версии и publicKeyToken, если он находится в GAC. Для некоторых простых настроек appSettings может быть проще. А для строгой типизации можно использовать простой класс-оболочку. - person Joe; 20.06.2009
comment
Я не понимаю, почему ссылки могут быть проблемой - мы не говорим о ненадежном стороннем компоненте, а скорее о части базовой платформы .NET. Если нужного System.Configuration.dll нет в GAC, ваше приложение, вероятно, вышло из строя. Что касается простого аргумента, он может иметь небольшое значение. Но создание простого класса раздела конфигурации и его подключение, с другой стороны, занимает около 3 минут. - person Wyatt Barnett; 20.06.2009
comment
мы не говорим о ненадежном стороннем компоненте - да, мы говорим о стороннем компоненте (нестабильном или ненадежном). Вам необходимо указать свой собственный ConfigurationSection: ‹section name = ... type = MyWonkyHandler ... - person Joe; 20.06.2009

arrow_upward
2
arrow_downward

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

«Потому что так проще».

person Doug L.    schedule 19.06.2009
comment
@Doug L. Думаю, если бы вы не использовали визуальную студию ... Я бы это увидел. (Примечание: я не тот, кто проголосовал против вас) - person blak3r; 19.06.2009
comment
@Doug Я проголосовал против, потому что не согласен. Это не проще, если вы используете Visual Studio, а если нет, то причина, по которой вы этого не сделаете, - отдельная тема (я не могу представить, почему !!!) - person TheSoftwareJedi; 19.06.2009
comment
@Jedi - но ты даже сказал ниже, ... потому что первые пару раз лепить их руками больно. Конечно, когда все на месте, все отлично. Но вначале app.config проще, и поэтому люди его используют. Я не сказал, что это лучше всего, просто просто. Это путь наименьшего сопротивления, и это ответ на вопрос. С уважением... :) - person Doug L.; 19.06.2009

arrow_upward
1
arrow_downward

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

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

Здесь побеждает подход «настроек».

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

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

person Joe    schedule 19.06.2009
comment
Я не согласен. Я использую настройки с приложениями, состоящими из относительно независимых сборок, каждая из которых требует нескольких простых настроек конфигурации. Кажется, проще иметь эти строго типизированные настройки, чем иметь константы для имен настроек app.config по всему вашему коду. - person TheSoftwareJedi; 19.06.2009
comment
@Joe Во втором сценарии ... Я думаю, вы хотели сказать app.config или appConfig, а не appSettings. Эти два разных метода действительно сложно описать, так как они кажутся очень похожими. - person blak3r; 19.06.2009
comment
@Jedi ... константы для имен настроек app.config по всему вашему коду - это немного похоже на соломинку: разумный способ использования appSettings - иметь помощников для строгой типизации и чтения настроек в одном месте (например, свойства статического класса). Но YMMV, я только сказал, что ими можно проще управлять. - person Joe; 20.06.2009

arrow_upward
1
arrow_downward

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

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

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

Обновлять:

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

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

person tm1    schedule 21.02.2013

arrow_upward
0
arrow_downward

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

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

person mnuzzo    schedule 19.06.2009
comment
@ indyK1ng И метод app.config, и файл настроек хранят значения по умолчанию в одном файле, который называется ‹exename› .config. Итак, проблема, которую вы представляете, является общей для обоих подходов. Целью этого поста было сравнить два подхода. - person blak3r; 19.06.2009
comment
Извините, я не очень хорошо знаком с тем, как работает Visual Studio, и подумал, что вы имеете в виду два разных файла. - person mnuzzo; 19.06.2009
comment
... В файле настроек хранятся значения по умолчанию в одном и том же файле. В монолитном exe это правда. Но для сборки DLL значения по умолчанию хранятся в коде, сгенерированном из файла конфигурации в проекте сборки - эти значения по умолчанию не обязательно должны присутствовать в файле конфигурации для exe, на котором размещена DLL. - person Joe; 20.06.2009

arrow_upward
0
arrow_downward

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

Win XP: c: \ Documents and Settings \% Username% \ Local Settings \ Application Data {Publisher Name} \

Победа 7: C: \ Users \% Username% \ AppData \ Local {Publisher Name} \

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

person mchicago    schedule 17.04.2012