2009-03-27 3 views
17

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

ответ

10

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

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

+2

Какие виды «безопасности и других последствий» вы имеете в виду? – quux

+0

Я не вижу, как последствия безопасности файловой системы каким-либо образом отличаются от системного реестра. – Alex

+0

Получение доступа к реестру в Windows 7 требует повышения, что во всей реальности не требуется, если вы не пытаетесь подключиться к реестру для таких вещей, как автозапуск и т. Д. Таким образом, я держусь подальше, поскольку мне нравится поддерживать мои системы как минимум привилегирован как можно скорее. –

2

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

Here's статья, в которой объясняется, как использовать ее в .Net.

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

+0

Обратите внимание, что файл в изолированном хранилище может быть доступен только одной конкретной сборке, поэтому вы не можете легко делать такие вещи, как удаление пользовательских настроек с IS в деинсталляторе. Это также утомительно вручную поиск файлов данных для устранения неполадок во время разработки. Необходим способ создания уникального ключа для использования компанией (например, CompanyName \ ProductName или GUID), так что несколько файлов .exe могут совместно использовать файлы данных, а разработчики/пользователи могут легко их подделать, если это необходимо. Так что IS мертв. Да здравствует% AppData%. –

5

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

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

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData); 

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

6

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

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

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

+1

неимущих пользователей нет, но тогда у них также будет непростая резервная копия файла в% APPDATA%/MyApp. Реестр легко экспортировать и импортировать - найдите свое дерево (в HKCU/Software/MyApp или everyree), щелкните правой кнопкой мыши и экспортируйте. Так же просто, как застежка каталога. – gbjbaanb

1

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

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

+0

Yikes! И я думал, что некоторые из моих применений в прошлом были плохими! (Нет, не хочу делиться!) –

+0

О, давай! Не стесняйтесь! Честно говоря, мы никому не скажем. – Treb

+0

Я не понимаю. Почему этот парень написал в реестр с одной частью своего приложения, а затем опросил и прочитал значение из реестра для отображения? Это кажется глупым, что не имеет никакого отношения к конкретному механизму настойчивости. – MusiGenesis

2

Я бы дифференцироваться:

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

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

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

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

4

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

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

+0

Кроме того, если вы действительно хотите быть дружественным к предприятию, вы можете целенаправленно читать настройки из раздела «Политики» в реестре и даже предоставлять шаблон ADM и/или ADMX для совместного использования с вашим приложением. –

15

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

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

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

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

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

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