Каким образом реестр Windows должен использоваться? Я знаю, что это хорошо, чтобы сохранить небольшое количество пользовательских настроек, но считается ли это плохим практикой хранить все ваши данные пользователей там? Я думаю, что это будет зависеть от набора данных, поэтому как насчет небольших объемов данных, скажем, менее 2 КБ, в 100 или около того разных пар ключ/значение. Это плохая практика? Будет ли более плотным файлом или SQLite db?
Передовые методы реестра Windows
Ответ 1
Для меня удобнее хранить простые пользовательские элементы конфигурации и пользовательские данные в файле конфигурации XML: SQLLite db или MS SQL Server Compact db. Точный носитель данных зависит от особенностей реализации.
Я использую реестр только для вещей, которые мне нужно установить нечасто, и что пользователям не нужно изменять/видеть. Например, я ранее хранил зашифрованную информацию о лицензии в реестре, чтобы избежать случайного удаления пользователем данных.
Ответ 2
Я собираюсь принять противоположный взгляд.
Реестр - прекрасное место для размещения данных конфигурации всех типов. В общем, он быстрее большинства конфигурационных файлов и более надежный (отдельные операции в реестре транслируются, поэтому, если ваше приложение падает во время записи, реестр не поврежден - в общем, это не так с ini файлами).
Marcelo MD абсолютно прав: сохранение таких вещей, как процент обработки, полный в реестре (или любое другое неволитарное хранилище), является ужасной идеей. С другой стороны, хранение данных, таких как самые последние используемые файлы, очень хорошо - реестр был создан именно для этой проблемы.
Несколько других комментаторов этого сообщения, рассказывающих о списке MRU, обсудили проблему того, что происходит, когда список MRU выходит из синхронизации из-за сбоев приложений. Мне интересно, почему лучше хранить список MRU в плоском файле в хранилище для каждого пользователя?
Я также не знаю, что такое "последствия для безопасности" для хранения ваших данных в реестре. Реестр настолько же безопасен, как и файловая система - реестр и файловая система используют один и тот же механизм ACL для защиты своих данных.
Если вы собираетесь хранить свои пользовательские данные в файле, вы должны поместить свои данные в% APPDATA%\CompanyName\ApplicationName по крайней мере - таким образом, если два разных разработчика создают приложение с тем же именем (сколько "Media Manager" там, где есть?), У вас не будет столкновений.
Ответ 3
Использование реестра для хранения данных имеет в основном одну проблему: она не очень удобна для пользователя. У пользователей практически нет возможности выполнять резервное копирование своих настроек, копирование их на другой компьютер, устранение неполадок (или их сброс), если они повреждены, или, как правило, просто посмотреть, что делает их программное обеспечение.
Мое правило состоит в том, чтобы использовать реестр только для связи с ОС. Ассоциации типов файлов, записи деинсталлятора, процессы для запуска при запуске, эти вещи, очевидно, должны быть в реестре.
Но данные, которые предназначены для использования в вашем приложении, принадлежат только файлу в папке "Данные приложения". (в любом случае, одна из 3+ папок данных приложения, которую Microsoft в настоящий момент хочет использовать)
Ответ 4
Поскольку у каждого пользователя есть пространство в Windows, которое уже предназначено для хранения пользовательских данных приложения, я использую его для хранения данных пользовательского уровня (например, предпочтений).
В С# я бы получил его, выполнив что-то вроде этого:
Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);
Как правило, я буду хранить файлы SQLite там или все, что подходит для приложения.
Ответ 5
Если ваше приложение будет развернуто "на предприятии", имейте в виду, что администраторы могут настраивать реестр с помощью инструментов групповой политики. Например, если firefox использовал реестр для таких вещей, как прокси-сервер, он бы быстро установил развертывание, поскольку администратор может использовать стандартные инструменты в активном каталоге для его настройки. Если вы используете что-то еще, я не думаю, что такие вещи можно сделать очень легко.
Поэтому не оставляйте реестр вместе. Если есть вероятность, что администратор может захотеть стандартизировать части вашей конфигурации по сети, установите этот параметр в реестр.
Ответ 6
Я думаю, что Microsoft поощряет использование изолированного хранилища вместо реестра Windows.
Вот статья, в которой объясняется, как использовать ее в .Net.
Эти файлы можно найти в Windows XP в разделе Документы и настройки\\Локальные настройки\Данные приложения\Изолированное хранилище. Данные находятся в .dat файлах
Ответ 7
Я бы выделил:
С одной стороны, существуют конкретные данные конфигурации приложения, необходимые для запуска приложения, например. IP-адреса для подключения, какие папки использовать для каких файлов и т.д. И нетривиальные для каждого пользователя настройки. Те, которые я вставлял в конфигурационный файл, ini-формат для простых вещей, xml, если он становится более сложным.
С другой стороны, тривиальные пользовательские настройки (лучший пример: расположение и макет окна). Чтобы избежать загромождения конфигурационных файлов (которые некоторые пользователи захотят редактировать сами, так мало и четко организованных записей являются обязательными), мне нравится помещать их в реестр (с консервативными настройками по умолчанию, установленными в приложении, если в реестре нет настроек можно найти).
Я в основном делаю это как istmatt sais: Я храню файлы конфигурации внутри папки %APPDATA%. Обычно в %APPDATA%\ApplicationName мне не нравится .NET по умолчанию APPDATA%\CompanyName\ApplicationName\Version, этот уровень детализации и сложности контрпродуктивен для большинства приложений малого и среднего размера.
Я не согласен с примером Marcelo MD не хранить недавно использованные файлы в реестре. IMO - это точно изменчивая пользовательская информация, которая может быть сохранена там. (Его пример того, что не делать очень хорошо, хотя!)
Ответ 8
Мне кажется, что легче подумать о том, что вы НЕ должны там положить. например: динамические данные, такие как редактор "последний файл открыт" и параметры проекта. Это очень раздражает, когда ваше приложение теряет синхронизацию с реестром (удаление файла, сбой системы и т.д.) И получает информацию, которая больше недействительна, возможно, блокирует пользователя.
На более ранней работе я увидел парня, который сохранил процент завершения передачи данных там, написание новых значений каждые 10 тыс. или около того, и с графическим интерфейсом извлекать это значение каждую секунду, чтобы он мог отображаться в заголовке.