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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

Дилана,

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

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

Answer 8

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

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

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

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