Лучшие практики реестра Windows

Question

Каким образом предполагается использовать реестр Windows? Я знаю, что можно хранить небольшое количество пользовательских настроек, но считается ли это плохой практикой хранить там все ваши пользовательские данные? Я думаю, что это будет зависеть от набора данных, так как насчет небольших объемов данных, скажем, менее 2 КБ, в 100 или около того разных парах ключ / значение. Это плохая практика? Будет ли лучше использовать обычный файл или базу данных SQLite?

Answer 1

Я собираюсь принять противоположный взгляд.

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

Marcelo MD абсолютно прав: хранение таких вещей, как процент выполнения операции в реестре (или любом другом энергонезависимом хранилище), является ужасной идеей. С другой стороны, хранение данных, таких как недавно использованные файлы, просто отлично - реестр был создан именно для такой проблемы.

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

Я также не уверен, каковы "последствия для безопасности" хранения ваших данных в реестре. Реестр так же безопасен, как и файловая система - реестр и файловая система используют один и тот же механизм ACL для защиты своих данных.

Если вы собираетесь хранить свои пользовательские данные в файле, вы должны как минимум поместить их в% APPDATA% \ CompanyName \ ApplicationName - таким образом, если два разных разработчика создают приложение с одинаковым именем (сколько) Media Manager "приложения там есть?) У вас не будет коллизий.

Answer 2

Для меня простые пользовательские элементы конфигурации и пользовательские данные лучше хранить либо в простом XML-файле конфигурации, либо в базе данных SQLLite, либо в базе данных MS SQL Server Compact. Точный носитель информации зависит от особенностей реализации.

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

Answer 3

Использование реестра для хранения данных имеет в основном одну проблему: он не очень удобен для пользователя. У пользователей практически нет шансов создать резервную копию своих настроек, скопировать их на другой компьютер, устранить их (или сбросить), если они повреждены, или, как правило, просто посмотреть , что делает их программное обеспечение.

Мое эмпирическое правило - использовать реестр только для связи с ОС. Ассоциации типов файлов, записи удаления, процессы, запускаемые при запуске, эти вещи, очевидно, должны быть в реестре.

Но данные, предназначенные для использования в вашем приложении, принадлежат только файлу в папке «Данные приложения». (в любом случае, одну из 3+ папок с данными приложения, которые Microsoft в настоящее время хочет, чтобы вы использовали)

Answer 4

Поскольку у каждого пользователя в Windows уже есть место для каталогов, предназначенное для хранения пользовательских данных приложения, я использую его для хранения данных уровня пользователя (например, предпочтений).

В C # я бы получил это, выполнив что-то вроде этого:

Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData);

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

Answer 5

Если ваше приложение будет развернуто «на предприятии», имейте в виду, что администраторы могут настроить реестр с помощью инструментов групповой политики. Например, если Firefox использует реестр для таких вещей, как прокси-сервер, развертывание будет проще, поскольку администратор может использовать стандартные инструменты в активном каталоге для его настройки. Если вы используете что-то еще, я не думаю, что такие вещи можно сделать очень легко.

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

Answer 6

Я бы дифференцировал:

С одной стороны, существуют специфические данные приложения, необходимые для его запуска, например, IP-адреса для подключения, какие папки использовать для каких файлов и т. Д., И нетривиально для пользовательских настроек. Те, что я положил в файл конфигурации, в формате INI для простых вещей, XML, если он становится более сложным.

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

Я делаю это в основном как istmatt sais: я храню файлы конфигурации внутри папки %APPDATA%. Обычно в %APPDATA%\ApplicationName мне не нравится .NET по умолчанию APPDATA%\CompanyName\ApplicationName\Version, такой уровень детализации и сложности контрпродуктивен для большинства приложений малого и среднего размера.

Я не согласен с примером Marcelo MD , который не хранит недавно использованные файлы в реестре. ИМО, это именно изменчивая информация о пользователях, которая может храниться там. (Однако его пример того, что не делать, очень хорош!)

Answer 7

Я думаю, что Microsoft поощряет использование изолированного хранилища вместо реестра Windows.

Вот статья, объясняющая, как использовать ее в .Net.

Эти файлы можно найти в Windows XP в разделе «Документы и настройки» \ «Локальные настройки» \ «Данные приложения» \ «Изолированное хранилище». Данные находятся в файлах .dat

Answer 8

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

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