ConfigurationManager.AppSettings Проблемы производительности

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

Дилан,

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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