Когда - и почему - необходимо хранить данные в Windows Registry?
Если вы хотите, чтобы значение # в TableViewB отличалось от 0, передайте это значение # в TableViewB.
Например:
if let vc = Utils.viewController(storyboardId: "WebViewController", storyboardName: "WebView") as? WebViewController {
vc.name = "Terms and Conditions" // pass #name to B
self.navigationController?.pushViewController(vc, animated: true)
}
13 ответов
- Первоначально (WIN3) конфигурация была сохранена в файле WIN.INI в каталоге окон.
- проблема: WIN.INI стал слишком большим.
- Решение (Win31): отдельные файлы INI в том же каталоге как программа.
- проблема: Та программа может быть установлена в сети и совместно использована многими людьми.
- Решение (Win311): отдельные файлы INI в каталоге Window пользователя.
- проблема: Многие люди могут совместно использовать папку окон, и это должно быть только для чтения так или иначе.
- Решение (Win95): Реестр с отдельными участками для каждого пользователя.
- проблема: Реестр стал слишком большим.
- Решение (WinXP): Большие блоки отдельных данных, перемещенных в собственную папку Application Data пользователя.
- проблема: Хороший для больших объемов данных, а скорее комплекса для небольших количеств.
- Решение (.NET): небольшие объемы фиксированных, данных только для чтения, хранивших в .config (Xml) файлы в той же папке как приложение, с API для чтения его. (Чтение-запись или пользователь определенные данные остаются в реестре)
Лично я использовал реестр для хранения путей установки для использования (ООН) сценарии установки. Я не уверен - ли это единственный возможный вариант, но походило на разумное решение. Это было для приложения, которое только использовалось в Windows, конечно.
В.NET действительно нет никогда потребности.
Вот 2 примера, которые показывают, как использовать Проект proerties, чтобы сделать это.
Эти примеры делают это Свойствами проекта пользователя Windows, но то же могло/могло быть сделанным Приложением также.
Больше здесь:
Я полагаю, что Windows Registry был хорошей идеей, но из-за большого злоупотребления от разработчиков приложений и стандартных политик не поощрил/передал под мандат Microsoft, превратился в неуправляемого зверя. Я очень не хочу использовать его по причинам, которые Вы упомянули, существуют однако некоторые случаи, что это имеет смысл с помощью него:
- Отъезд трассировки Вашего приложения после Вашего приложения был удален (например, помните предпочтения пользователя в случае, если приложение установлено снова)
- параметры конфигурации Доли между различными приложениями - компоненты
Прибытие в это и с пользовательской точки зрения и с перспективы программистов, которую я должен был бы сказать там действительно, не является хорошим exceuse для помещения чего-то в реестр, если это не что-то как ассоциации файлов или машина определенные настройки.
я происхожу из философской школы, которая говорит, что программа должна быть выполнимой от того, везде, где она установлена, что установка должна быть абсолютно подвижной в машине, или даже к другой машине и не влиять на выполнение ее.
Любые настраиваемые опции или требуемый dlls и т.д., если они не совместно используются, должны находиться в подкаталоге каталога установки, так, чтобы целая установка была легко перемещена.
я использую много меньшей утилиты как программы, поэтому если она наклон быть установленной на usb придерживается и включенной другая машина и просто выполненной, затем не для меня.
Политика Microsoft:
- Перед Windows 95, мы использовали ini файлы для данных приложения.
- В Windows 95 - эра XP, мы использовали реестр.
- От Windows Vista, мы используем ini файлы, хотя они теперь xml базирующиеся.
реестр является зависимым машины. Мне никогда не нравился он, потому что его получение для замедления и почти невозможно найти вещь, в которой Вы нуждаетесь. Вот почему мне нравятся простой ini или другие файлы установки. Вы знаете, где они (папка приложения или пользовательская папка), таким образом, они - легкое портативное устройство, и человекочитаемый.
Чтения реестра и записи ориентированы на многопотоковое исполнение, но файлы не. Таким образом, это зависит от того, является ли Ваша программа единственной, распараллелил.
Мир собирается закончиться при хранении нескольких положений окна и списка последний раз используемых объектов в реестре Windows? Это работало хорошо на меня до сих пор.
HKEY-CURRENT-USER является великолепным местом, чтобы хранить тривиальные пользовательские данные в небольших количествах. Это - то, для чего это. Кажется глупым не использовать для его намеченной цели просто, потому что другие злоупотребили им.
Настройки, которые Вы хотите иметь в наличии в профиле роуминга пользователя, должны, вероятно, войти в реестр, если Вы на самом деле не хотите перейти к усилию по поиску папки Application Data пользователя вручную. :-)
, Когда - Вы вынуждены к должному к интеграции прежней версии или потому что системный администратор Вашего клиента говорит, "это должно быть так" или потому что Вы разрабатываете на более старом языке, который делает более трудным использовать XML.
, Почему - Прежде всего, потому что реестр не является столь же портативным как копирование файла конфигурации, который сидит рядом с приложением (и назван почти тем же).
при использовании.Net2 +, у Вас есть Приложение. Конфигурация и Пользователь. Файлы конфигурации и Вы не должны регистрировать DLL в реестре, так держитесь подальше от него.
Файлы конфигурации имеют свои собственные проблемы (см. ниже), но они могут быть кодированы вокруг, и можно изменить архитектуру.
- проблема: для Приложений были нужны конфигурируемые параметры.
- Решение: настройки Хранилища в файле (WIN.INI) в папке Windows - используют заголовки раздела для группировки данных (Win3.0).
- проблема: файл WIN.INI стал слишком большим (и стал грязным).
- Решение: настройки Хранилища в файлах INI в той же папке как проблема приложения (Win3.1).
- : нужны определенные для пользователя настройки.
- Решение: пользовательские настройки Хранилища в определенных для пользователя файлах INI в каталоге (Win3.11) Window пользователя или определенных для пользователя разделах в приложении файл INI.
- проблема: безопасность - некоторые параметры настройки приложения должны быть только для чтения.
- Решение: Реестр с безопасностью, а также определенными для пользователя и разделами всей машины (Win95).
- проблема: Реестр стал слишком большим.
- Решение: определенный для пользователя реестр, перемещенный в user.dat в собственной папке "Application Data" пользователя и только загруженный при входе в систему (WinNT).
- проблема: В больших корпоративных средах Вы входите в систему несколько машин и должны настроить КАЖДОГО.
- Решение: Дифференцируйтесь между локальным (Local Settings), и бродящий (по Данным приложения) представляет (WinXP).
- проблема: не Может скопировать с помощью xcopy развертывают или перемещают приложения как остальная часть .NET.
- Решение: XML-файл APP.CONFIG в той же папке как приложение - легкий читать, легкий управлять, легкий переместиться, может отследить, если изменено (.Net1).
- проблема: Все еще потребность хранить определенные для пользователя данные в подобном (т.е. xcopy развертываются), способ.
- Решение: XML-файл USER.CONFIG в локальной или бродящей папке пользователя и со строгим контролем типов (.Net2).
- проблема: Файлы конфигурации чувствительны к регистру (не интуитивный людям), требуют очень определенных открытых/близких "тегов", строки подключения не могут быть установлены во времени выполнения, проекты установки не могут записать настройки (как легко как реестр), не может легко определить user.config файл, и пользовательские настройки унесены с каждым новым установленным пересмотром.
- Решение: Используйте участника ОБЪЕКТА, чтобы установить строки подключения во времени выполнения, написать код в классе Установщика для изменения Приложения. Конфигурация во время установки и используют параметры настройки приложения в качестве значений по умолчанию, если пользователь, устанавливающий, не найден.
Если Вы разрабатываете новое приложение, и Вы заботитесь о мобильности, Вы должны НИКОГДА , хранят данные в реестре окон, так как другая ОС не имеет (окна) реестра (понятное дело примечание - это может быть очевидно, но часто пропускается).
, Если Вы только разрабатываете для платформ Win..., стараются избегать его как можно больше. Файлы конфигурации (возможно зашифрованный) являются путем лучшее решение. Нет никакого усиления в том, чтобы хранить данные в реестр - (изолированное устройство хранения данных является намного лучшим решением, например, при использовании.NET).
Немного вне темы, но так как я вижу людей, обеспокоенных мобильностью, лучший подход, который я когда-либо использовал, является классом QSettings QT. Это абстрагирует устройство хранения данных настроек (реестр в Windows, предпочтительный файл XML на файлах Mac OS и Ini на Unix). Как клиент класса, я не должен тратить мозговой цикл, задающийся вопросом о реестре или чем-либо еще, это Просто Работы (TM).
Обычно, если Вы не помещаете настройки в реестр, Вы используете его главным образом для получения текущих настроек Windows, ассоциаций файлов изменения, и т.д.
Теперь, если необходимо обнаружить, если программное обеспечение уже установлено, можно сделать минимальную запись в реестре, это - местоположение, которое можно найти назад в любой конфигурации. Или ищите папку имени в Данных приложения.
, Если я смотрю на свою папку Document и Settings, я вижу партию программного обеспечения с помощью записи через точку Unix для установки папок: .p4qt .sqlworkbench .squirrel-sql.SunDownloadManager .xngr .antexplorer .assistant.CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (и т.д.).
и в Данных приложения, различных папках с именами редактора или названиями программного обеспечения. Похож на то, чтобы быть современной тенденцией, по крайней мере, среди портативных приложений...
WinMerge использует немного отличающийся подход, храня данные в реестре, но предлагая Импорт и Экспорт опций в диалоговом окне конфигурации.