ConfigurationManager.AppSettings Проблемы производительности
Я планирую сохранить все мои настройки конфигурации в разделе app.config моего приложения (используя ConfigurationManager.AppSettings учебный класс). Поскольку пользователь изменяет настройки с помощью пользовательского интерфейса приложения (щелкая флажки, выбирая переключатели и т. Д.), Я планирую записать эти изменения в AppSettings, В то же время, пока программа работает, я планирую получить доступ к AppSettings постоянно от процесса, который будет постоянно обрабатывать данные. Изменения настроек через пользовательский интерфейс должны влиять на обработку данных в режиме реального времени, поэтому процесс будет получать доступ к AppSettings постоянно.
Это хорошая идея в отношении производительности? С помощью AppSettings Предполагается, что это "правильный путь" для хранения и доступа к настройкам конфигурации при написании приложений.Net, но я беспокоюсь, что этот метод не предназначен для постоянной загрузки (по крайней мере, с точки зрения постоянно читаемых настроек).
Если у кого-то есть опыт с этим, я был бы очень признателен за вклад.
Обновление: я, вероятно, должен уточнить несколько моментов.
Это не веб-приложение, поэтому подключение базы данных к приложению может оказаться излишним просто для хранения параметров конфигурации. Это приложение Windows Forms.
Согласно документации MSDN, ConfigurationManager предназначен для хранения не только настроек уровня приложения, но и пользовательских настроек. (Особенно важно, если, например, приложение установлено как приложение с частичным доверием.)
Обновление 2: я принял ответ lomaxx, потому что Properties действительно выглядит как хорошее решение, без необходимости добавлять какие-либо дополнительные слои в мое приложение (например, базу данных). При использовании свойств он уже выполняет все кэширование, предложенное другими. Это означает, что любые изменения и последующие операции чтения выполняются в памяти, что делает его чрезвычайно быстрым. Свойства только записывают изменения на диск, когда вы явно указываете это. Это означает, что я могу вносить изменения в параметры конфигурации "на лету" во время выполнения, а затем делать окончательное сохранение на диск только при выходе из программы.
Просто чтобы убедиться, что он действительно сможет справиться с нагрузкой, которая мне нужна, я провел некоторое тестирование на своем ноутбуке и смог выполнить 750000 операций чтения и 7 500 операций записи в секунду, используя Properties. Это намного выше того, что моему приложению когда-либо даже понадобится, и я чувствую себя в безопасности при использовании свойств без ущерба для производительности.
8 ответов
Так как вы используете приложение winforms, если оно в.net 2.0, на самом деле существует система пользовательских настроек (называемая свойствами), которая предназначена для этой цели. Эта статья на MSDN имеет довольно хорошее введение в это
Если вы по-прежнему беспокоитесь о производительности, взгляните на SQL Compact Edition, который похож на SQLite, но это предложение от Microsoft, которое, как я обнаружил, прекрасно работает с winforms, и даже есть возможность заставить его работать с Linq
AppSettings на самом деле не предназначен для того, что вы пытаетесь сделать.
Когда ваше приложение.NET запускается, оно читает файл app.config и кэширует его содержимое в памяти. По этой причине после записи в файл app.config вам придется каким-то образом принудительно заставить среду выполнения повторно проанализировать файл app.config, чтобы он снова мог кэшировать настройки. Это ненужно
Наилучшим подходом будет использование базы данных для хранения ваших настроек конфигурации.
Запрет на использование базы данных, вы можете легко настроить внешний файл конфигурации XML. Когда ваше приложение запускается, вы можете кэшировать его содержимое в объекте NameValueCollection или объекте HashTable. Когда вы меняете / добавляете настройки, вы делаете это с этой кэшированной копией. Когда ваше приложение закрывается или через соответствующий интервал времени, вы можете записать содержимое кэша обратно в файл.
Проверьте SQLite, он кажется хорошим вариантом для этого конкретного сценария.
Дилан,
Не используйте файл конфигурации приложения для этой цели, используйте базу данных SQL (SQLite, MySQL, MSSQL и т. Д.), Потому что вам придется меньше беспокоиться о проблемах параллелизма во время чтения и записи в файл конфигурации.
У вас также будет больше гибкости в типе данных, которые вы хотите хранить. Раздел appSettings - это просто список ключей / значений, который вы можете перерастать с течением времени и по мере развития приложения. Вы можете использовать пользовательские разделы конфигурации, но тогда вы окажетесь в новой проблемной области, когда дело доходит до дизайна.
Я бы не стал использовать конфигурационные файлы для хранения пользовательских данных. Используйте БД.
Кто-то исправит меня, если я ошибаюсь, но я не думаю, что AppSettings обычно предназначен для такого типа настроек конфигурации. Обычно вы устанавливаете только те параметры, которые остаются довольно статичными (строки подключения к базе данных, пути к файлам и т. Д.). Если вы хотите сохранить настраиваемые пользовательские настройки, было бы лучше создать отдельный файл настроек или в идеале сохранить эти настройки в базе данных.
Одна вещь, на которую я бы обратил внимание, - это кэширование настроек приложения при чтении, а затем сброс настроек из кэша при записи, что должно минимизировать фактическую нагрузку, с которой сервер сталкивается при обработке appSettings.
Также, если возможно, посмотрите на разбиение appSettings на configSections, чтобы вы могли читать настройки, связанные с записью и кэшированием.
Сказав все это, я бы серьезно подумал о том, чтобы посмотреть на сохранение этих значений в базе данных, поскольку вы, похоже, на самом деле храните пользовательские настройки, а не настройки приложения.
Могу я спросить, почему вы не сохраняете настройки пользователя в базе данных?
Обычно я сохраняю настройки приложения, которые меняются очень редко, в разделе appSettings (на которые отправляются журналы ошибок адреса электронной почты по умолчанию, количество минут, по истечении которых вы автоматически выходите из системы, и т. Д.), не у пользователя, и обычно используется для настройки развертывания.