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

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

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

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

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

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

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

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

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

7.08.2008 00:12:55
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

10
1.11.2008 16:12:39

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

1
7.08.2008 00:26:39

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

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

0
7.08.2008 00:27:36

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

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

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

0
7.08.2008 00:28:58

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

2
7.08.2008 00:41:38

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

1
7.08.2008 00:43:11

Дилан,

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

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

2
7.08.2008 00:56:26

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

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

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

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

2
7.08.2008 01:10:36