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

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

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

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

<code>string configValue = Configuration.AppSettings["ConfigValueName"];
</code>

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

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

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

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

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

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

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

 blak3r19 июн. 2009 г., 19:22
У меня нет предвзятости. Мне действительно любопытно, каковы преимущества, так как люди, кажется, используют его чаще. Спасибо за предложение, хотя. Я перефразирую
 TheSoftwareJedi19 июн. 2009 г., 14:59
Ваше название, кажется, указывает на предвзятость. Вы получите лучшие ответы, если вы сделаете его более подходящим для свойств приложения. Вот почему люди начинают защищаться. Некоторые люди выдвигают такие закрытые вопросы, поэтому будьте осторожны с ними :)

Ответы на вопрос(7)

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

Win XP: c: \ Documents and Settings \% Имя пользователя% \ Local Settings \ Application Data {Имя издателя} \ Win 7: C: \ Users \% Username% \ AppData \ Local {Имя издателя} \ Пока настройки app.config сохраняются только в файле конфигурации.

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

чем 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.

 Wyatt Barnett19 июн. 2009 г., 21:32
Смотрите обновление для комментариев. @ TheSoftwareJedi - я играю с идеей очень часто, но она довольно ужасно сложна, так как API такой богатый. Я думаю, что пользовательские фрагменты VS - хороший способ справиться с этим самостоятельно, но я всегда забываю писать упомянутые фрагменты, так как обычно они пишутся один раз для каждого проекта.
 TheSoftwareJedi19 июн. 2009 г., 14:41
Согласовано. Кто-то должен сделать код gen для этого, потому что ручная лепка их первые пару раз болезненна.
 Wyatt Barnett19 июн. 2009 г., 23:52
Я не понимаю, как ссылки могут быть проблемой - мы говорим не о стороннем компоненте, а скорее о ядре .NET Framework. Если нужного файла System.Configuration.dll нет в GAC, возможно, ваше приложение неисправно. Что касается простого аргумента, у него может быть небольшая заслуга. Но может потребоваться 3 минуты, чтобы создать простой класс раздела конфигурации и подключить его с другой стороны.
 blak3r19 июн. 2009 г., 19:18
Должно быть, что-то здесь не хватает. 1) DISAGREE Файлы настроек также строго типизированы 2) Проверка может быть проведена с помощью файлов настроек ... Я лично никогда не делал этого, так как это не очевидно при использовании поддержки vs designer 3) Не совсем уверен в этом ... пожалуйста, объясните ... 4) Нет волшебных строк, использующих подход «Настройки». 5) DISAGREE - то же самое можно сделать, используя несколько файлов настроек ... у каждого будет свой собственный раздел. 6) Согласен. ------- Итак, я не согласен с вашими "преимуществами" и есть много недостатков ...
 Joe19 июн. 2009 г., 23:20
Я согласен, что пользовательские разделы конфигурации часто полезны. Но они добавляют некоторую сложность: например, вам нужно сослаться на сборку, которая определяет их в разделе <configSections> - с правильным номером версии и publicKeyToken, если он находится в GAC. Для нескольких простых настроек appSettings может быть проще. А простой класс-обёртка может использоваться для строгой типизации.

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

 Doug L.19 июн. 2009 г., 17:48
@ Джедай - но ты даже сказал ниже: «... потому что ручная лепка их первые пару раз болезненна». Конечно, когда все это на месте, это здорово. Но в начале app.config проще, и поэтому люди его используют. Я не сказал, что это было лучше, просто легко. Это путь наименьшего сопротивления, и это ответ на вопрос. С уважением... :)
 TheSoftwareJedi19 июн. 2009 г., 13:54
@ Дауг, я понизил голос, потому что я не согласен. Это не легче, если вы используете Visual Studio, а если нет, то причина, по которой вас не было бы, это отдельная тема (я не могу представить, почему !!!)
 blak3r19 июн. 2009 г., 09:59
@ Дуг Л. Я думаю, если бы ты не использовал визуальную студию ... Я бы это видел. (Примечание: я не тот, кто за вас проголосовал)

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

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

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

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

 blak3r19 июн. 2009 г., 18:57
@Joe Во втором вашем сценарии ... Я думаю, что вы хотели сказать "app.config" или "appConfig", а не appSettings. Трудно описать эти два разных метода, так как они звучат очень похоже.
 TheSoftwareJedi19 июн. 2009 г., 13:55
Я не согласен. Я использую Настройки с приложениями, состоящими из относительно независимых сборок, каждая из которых требует нескольких простых настроек конфигурации. Кажется, проще иметь эти строго типизированные Настройки, чем иметь константы для имен настроек app.config во всем вашем коде.
 Joe19 июн. 2009 г., 22:29
@Jedi "... константы для имен настроек app.config во всем вашем коде" - это немного глупо: разумный способ использовать appSettings - иметь помощников для строгой типизации и читать настройки в одном месте ( например, свойства статического класса). Но YMMV, я только сказал, что ониМожно быть проще в управлении.

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

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

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

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

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

 Chris Thompson20 июн. 2009 г., 08:32
Хорошая точка зрения. Разве главная проблема в app.config заключается в том, что приложение не может изменять значения? Например, я не могу написать графический интерфейс, чтобы позволить пользователю настраивать свои настройки и сохранять эти настройки в app.config. Я могу сделать это с помощью подхода настроек.
 blak3r16 февр. 2012 г., 00:05
@ChrisThompson - полностью согласен с вонением в файле настроек ... но все же не объясняет, почему app.config кажется более популярным. Ну что ж.
 blak3r19 июн. 2009 г., 09:26
@Chris Thompson: я согласен, что есть ряд проблем с использованием файлового подхода настроек. Но цель этого поста - обсудить, почему люди рекомендуют вручную изменять app.config INSTEAD для использования файлов настроек. Как я упоминал выше, у меня, конечно, есть разногласия с файлами настроек и, следовательно, почему они свернули свой собственный файл конфигурации. Вы коснулись одного из них.
 Paul Farry19 июн. 2009 г., 09:19
Я также предпочёл бы подход Криса, я использовал свой собственный класс настроек гораздо эффективнее, чем автоматический

статочно документирована, учитывая ее сложность.

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

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

Обновить:

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

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

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

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

 blak3r19 июн. 2009 г., 09:30
@ indyK1ng И метод app.config, и файл настроек сохраняют значения по умолчанию в одном файле <exename> .config. Итак, эта проблема, которую вы представляете, является общей для обоих подходов. Целью этого поста было сравнить два подхода.
 mnuzzo19 июн. 2009 г., 10:19
Извините, я не очень знаком с тем, как работает Visual Studio, и думал, что вы имеете в виду два разных файла.
 Joe19 июн. 2009 г., 22:35
Msgstr "... оба файла настроек хранят значения по умолчанию в одном файле". В монолитном exe это правда. Но для сборки DLL значения по умолчанию хранятся в коде, сгенерированном из файла конфигурации в проекте сборки - эти значения по умолчанию не обязательно должны присутствовать в файле конфигурации для исполняемого файла, в котором размещена DLL.

Ваш ответ на вопрос