Я - новый программист Windows, и я не уверен, где я должен хранить настраиваемые пользователем параметры приложения. Я понимаю необходимость предоставления пользователю удобных средств для изменения настроек приложения, таких как Edit | Форма настроек или аналогичная. Но где я должен хранить значения после того, как пользователь нажмет кнопку «Применить» в этой форме?
Каковы плюсы и минусы хранения настроек в реестре Windows по сравнению с хранением их в локальном INI-файле, конфигурационном файле или аналогичном?
Плюсы конфигурационного файла:
- Легко сделать. Не нужно знать никаких вызовов Windows API. Вам просто нужно знать интерфейс ввода / вывода файлов вашего языка программирования.
- Портативный. Если вы портируете свое приложение на другую ОС, вам не нужно менять формат настроек.
- Пользователь редактируемый. Пользователь может редактировать конфигурационный файл вне выполняемой программы.
Плюсы реестра:
- Закрепить. Пользователь не может случайно удалить файл конфигурации или повредить данные, если он / она не знает о regedit. И тогда пользователь просто напрашивается на неприятности.
- Я не опытный программист Windows, но я уверен, что использование реестра облегчает выполнение других специфичных для Windows вещей (пользовательских настроек, настроек сетевого администрирования, таких как групповая политика или что-то еще).
Если вам нужен простой способ хранения информации о конфигурации, я бы порекомендовал файл конфигурации, используя INI или XML в качестве формата. Я предлагаю использовать реестр, только если есть что-то конкретное, что вы хотите использовать при использовании реестра.
Согласно документации для GetPrivateProfileString , вы должны использовать реестр для хранения информации об инициализации.
Тем не менее, в так говоря, если вы все еще хотите использовать INI - файлы, а также использовать стандартные API для профилей ( GetPrivateProfileString
, WritePrivateProfileString
и т.п.) для доступа к ним, они обеспечивают встроенные способы автоматического предоставления «виртуальные файлы .ini» , подкрепленные реестр. Win-выиграть!
Там есть аналогичный вопрос здесь , что охватывает некоторые плюсы и минусы.
Я бы посоветовал не использовать реестр, если это не нужно вашему приложению. Насколько я понимаю, Microsoft пытается препятствовать использованию реестра из-за гибкости файлов настроек. Кроме того, я бы не рекомендовал использовать файлы .ini, а вместо этого использовать некоторые встроенные функции в .Net для сохранения настроек пользователя / приложения.
Я согласен с Дэниелом. Если это большое приложение, я думаю, что я делаю вещи в реестре. Если это небольшое приложение, и вы хотите, чтобы его аспекты настраивались пользователем без создания формы конфигурации, перейдите к быстрому INI-файлу.
Обычно я выполняю синтаксический анализ следующим образом (если формат файла .ini - option = value, 1 в строке, комментарии начинаются с #):
static void Parse()
{
StreamReader tr = new StreamReader("config.ini");
string line;
Dictionary<string, string> config = new Dictionary<string, string>();
while ((line = tr.ReadLine()) != null)
{
// Allow for comments and empty lines.
if (line == "" || line.StartsWith("#"))
continue;
string[] kvPair = line.Split('=');
// Format must be option = value.
if (kvPair.Length != 2)
continue;
// If the option already exists, it's overwritten.
config[kvPair[0].Trim()] = kvPair[1].Trim();
}
}
Изменить: Извините, я думал, что вы указали язык. Реализация выше в C #.
Это ваше приложение, которое установлено с программой установки, или это просто «Извлечь и запустить»? В первом случае посмотрите на плюсы и минусы, изложенные здесь. Но для Извлечения и запуска Реестр, по моему мнению, является «запретным», так как люди ожидают, что смогут просто удалить папку приложения, чтобы избавиться от вашей программы.
Как указал Даниэль, хранение данных конфигурации в реестре дает вам возможность использовать шаблоны администратора. То есть вы можете определить шаблон администратора, использовать его в групповой политике и управлять конфигурацией вашего приложения в масштабах всей сети. В зависимости от характера приложения, это может быть большим благом.
Есть еще одно преимущество использования INI-файла перед реестром, о котором я не упоминал: если пользователь использует какое-то шифрование на основе тома / файла, он может довольно легко зашифровать INI-файл. С реестром это, вероятно, будет более проблематичным.
У Джеффа Этвуда есть отличная статья о реестре Windows и о том, почему лучше использовать файлы .INI.
Моя жизнь была бы намного проще, если бы настройки для каждого приложения были сохранены в месте, где я мог бы легко их видеть, манипулировать ими и резервировать их. Мол, скажем ... в файлах INI.
- Реестр является единственной точкой отказа . Вот почему каждый совет по редактированию реестра, который вы когда-либо найдете, начинается с громкого кричащего заявления об отказе от того, как вы можете сломать свой компьютер с помощью regedit.
- Реестр непрозрачный и двоичный . Как бы мне не нравился налог на угловые скобки, по крайней мере, XML-файлы конфигурации достаточно удобочитаемы, и они допускают столько комментариев, сколько вы считаете нужным.
- Реестр должен быть синхронизирован с файловой системой . Удалите приложение, не «удаляя» его, и вы останетесь с устаревшей регистрацией. Или если приложение имеет плохо написанный деинсталлятор. Файловая система больше не является оператором записи - она должна как-то синхронизироваться с реестром. Это полное нарушение принципа СУХОЙ.
- Реестр монолитный . Допустим, вы хотели переместить приложение по другому пути на вашей машине или даже на другую машину в целом. Удачи в извлечении соответствующих настроек для этого конкретного приложения из гигантского архива реестра. У определенного приложения обычно есть десятки параметров, разбросанных по всему реестру.
Реестр оптимизирован для быстрого доступа и легкого обновления, и это единственный способ сделать некоторые специфические для Windows вещи, такие как связь с расширением. И вы можете проигнорировать аргумент об удалении одного каталога для удаления вашей программы - Windows Vista не позволит вам изменять файлы в каталоге Program Files, поэтому ваша конфигурация в любом случае должна будет перейти в другую папку.
Существует общее руководство по программированию Windows - делайте то, что от вас ожидает Microsoft, и ваша жизнь станет намного проще.
Тем не менее, я вижу апелляцию в файле INI, и я бы не стал никого обвинять в рассмотрении этого.
Использование ini-файла в том же каталоге, что и приложение, позволяет создавать резервные копии его вместе с приложением. Поэтому после перезагрузки операционной системы вы просто восстанавливаете каталог приложения и получаете свою конфигурацию так, как вам этого хочется.
Есть один недостаток файлов ini или config, который заключается в их расположении, если у пользователя есть возможность выбрать, где установлена программа.
GetFinalPathNameByHandle
. Существующие ответы охватывают много вопросов, но я подумал, что упомяну еще один момент.
Я использую реестр для хранения общесистемных настроек. То есть, когда 2 или более программ нуждаются в одинаковых настройках. Другими словами, настройка используется несколькими программами.
Во всех других случаях я использую локальный файл конфигурации, который находится по тому же пути, что и исполняемый файл, или на один уровень ниже (в каталоге конфигурации). Причины уже описаны в других ответах (переносимых, могут быть отредактированы с помощью текстового редактора и т. Д.).
Зачем ставить общесистемные настройки в реестр? Ну, я обнаружил, что если настройка является общей, но вы используете локальные конфигурационные файлы, вы в конечном итоге дублируете настройки. Это может означать, что вам в конечном итоге потребуется изменить настройку в нескольких местах.
Например, скажем, программа A и программа B указывают на одну и ту же базу данных. У вас может быть «общесистемный» параметр реестра для строки подключения. Если вы хотите указать другую базу данных, вы можете изменить строку подключения в одном месте, и обе программы теперь будут работать с другой базой данных.
Примечание. Нет смысла использовать реестр таким образом, если двум или более программам не нужно использовать одинаковые значения. Например, программе A и программе B требуется строка подключения к базе данных, которая может быть одинаковой, но не всегда. Например, я хочу, чтобы программа B теперь использовала тестовую базу данных, но программа A должна продолжать использовать производственную базу данных.
В приведенном выше примере вы можете иметь некоторые локальные настройки конфигурации, переопределяющие общесистемные настройки, но это может стать слишком сложным для простых задач.
Другой недостаток использования реестра заключается в том, что если вы работаете в смешанной среде с 32- и 64-разрядными приложениями, это является проблемой, так как системный вызов для доступа к реестру случайным образом (*) добавит \Wow6432Node\
к вашему пути в реестре, что сделает вас сумасшедшим во время отладки ,
(* конечно не случайно, но очень легко заблудиться)