Проблемы с конфигурацией ConfigurationManager.AppSettings

Я планирую хранить все свои настройки в разделе приложения app.config(используя класс ConfigurationManager.AppSettings). Поскольку пользователь меняет настройки с помощью пользовательского интерфейса приложения (нажатие флажков, выбор переключателей и т.д.), Я планирую записать эти изменения в AppSettings. В то же время, пока программа работает, я планирую постоянно обращаться к AppSettings из процесса, который будет постоянно обрабатывать данные. Изменения настроек с помощью пользовательского интерфейса должны влиять на обработку данных в режиме реального времени, поэтому процесс будет постоянно обращаться к AppSettings.

Это хорошая идея в отношении производительности? Использование AppSettings должно быть "правильным способом" для хранения и доступа к настройкам конфигурации при написании приложений .Net, но я опасаюсь, что этот метод не предназначен для постоянной нагрузки (по крайней мере, с точки зрения постоянно читаемых настроек).

Если у кого-то есть опыт с этим, я был бы очень признателен за ввод.

Обновление: Я должен, вероятно, уточнить несколько моментов.

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

В соответствии с документацией MSDN, ConfigurationManager предназначен для хранения не только настроек уровня приложения, но и пользовательских настроек. (Особенно важно, если приложение, например, установлено как приложение с частичным доверием.)

Обновление 2: Я принял ответ lomaxx, потому что Properties действительно выглядит как хорошее решение, без необходимости добавлять какие-либо дополнительные слои в мое приложение (например, базу данных). При использовании свойств он уже выполняет все кэширование, которое предложили другие. Это означает, что все изменения и последующие чтения выполняются в памяти, что делает его чрезвычайно быстрым. Свойства только записывают изменения на диск, когда вы явно указываете. Это означает, что я могу вносить изменения в настройки конфигурации "на лету" во время выполнения, а затем выполнять только окончательную запись на диск при выходе из программы.

Просто чтобы убедиться, что он действительно сможет обрабатывать требуемую нагрузку, я провел некоторое тестирование на своем ноутбуке и смог сделать 750 000 чтений и 7500 записей в секунду с помощью "Свойства". Это намного выше и выше того, что мое приложение когда-либо даже приблизится к необходимости, чтобы я чувствовал себя в безопасности при использовании "Свойства", не влияя на производительность.

Ответ 1

так как вы используете приложение winforms, если оно в .net 2.0 действительно имеет систему пользовательских настроек (называемую свойствами), предназначенную для этой цели. Эта статья о MSDN имеет довольно хорошее представление об этом

Если вы все еще беспокоитесь о производительности, посмотрите на SQL Compact Edition, который похож на SQLite, но является предложением Microsoft, которое Я нашел игры очень красиво с winforms и там даже способность заставить его работать с Linq

Ответ 2

Проверьте SQLite, это похоже на хороший вариант для этого конкретного сценария.

Ответ 3

Дилан,

Не используйте файл конфигурации приложения для этой цели, используйте SQL DB (SQLite, MySQL, MSSQL, независимо), потому что вам придется меньше беспокоиться о проблемах concurrency во время чтения и записи в файл конфигурации.

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

Ответ 4

AppSettings на самом деле не предназначен для того, что вы пытаетесь сделать.

Когда приложение .NET запускается, оно читается в файле app.config и кэширует его содержимое в памяти. По этой причине, после того, как вы напишете файл app.config, вам придется каким-то образом заставить среду выполнения повторно разбить файл app.config, чтобы он снова мог кэшировать настройки. Это необязательно

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

Запрет использования базы данных позволяет легко настроить внешний файл конфигурации XML. Когда приложение запускается, вы можете кэшировать его содержимое в объекте NameValueCollection или в объекте HashTable. Когда вы меняете/добавляете настройки, вы делаете это с помощью этой кешированной копии. Когда ваше приложение отключится или с соответствующим интервалом времени, вы можете записать содержимое кэша обратно в файл.

Ответ 5

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

Ответ 6

Я бы не использовал конфигурационные файлы для хранения пользовательских данных. Используйте db.

Ответ 7

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

Как правило, я сохраняю настройки приложения, которые очень редко изменяются в разделе appSettings (по умолчанию отправляются журналы ошибок по умолчанию для адресов электронной почты, количество минут, после которых вы автоматически выходите из системы, и т.д.). в приложении, а не у пользователя, и обычно используется для настроек развертывания.

Ответ 8

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

Кроме того, если возможно, посмотрите, как разбить AppSettings на configSections, чтобы вы могли прочитать настройки, связанные с записью и кешем.

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