Найкращий спосіб збереження налаштувань програми


17

У Windows типовим способом є реєстр. Це дозволяє диференціювати загальносистемні та індивідуальні налаштування.

У Unix слід використовувати текстові файли в папці / etc для загальносистемних налаштувань (яка умова для налаштувань для кожного користувача?).

У багатьох нових програмах (особливо в тих, що розроблені для портативного використання) використовуються файли XML.

  • Який найкращий спосіб (та місцеположення) для зберігання налаштувань, які не є BLOB?
  • Чи слід дотримуватися кожного системного замовчування чи мати єдине рішення?
  • І який найкращий портативний спосіб?

Будь ласка, будьте дуже конкретні щодо того, що ви маєте на увазі під "найкращим".

3
@ Thorbjørn: кращий adj \ ˈbest \ superlative of good
Wizard79

3
ви були б здивовані різноманітністю значень "кращий" на сайтах StackExchange.

Відповіді:


23

Який найкращий спосіб (та місцеположення) для зберігання налаштувань, які не є BLOB?

У Windows видається прийнятним використовувати реєстр. На мою думку, реєстр був погано розробленою системою, і замість цього Users\Username\AppDataслід віддавати перевагу простому текстовому файлу в каталозі. Це легше створити резервну копію, менш небезпечно для користувачів модифікувати та легше очистити.

У Linux та більшості Unixes кращим місцем розташування є /home/user/.config/appnameспецифічні для користувача настройки та /etc/глобальні (загальносистемні) налаштування. Менш переважне (але прийнятне) місце розташування для налаштувань користувача є ~/.appname, але це, як правило, не сприятливо. Ці файли повинні редагуватися користувачем, тому формат, прочитаний людиною, завжди є кращим.

Я не погоджуюсь з більшістю людей, що XML є прийнятним форматом для зберігання даних, що не стосуються блоку. На мій погляд, це завищений і надмірно складний формат для того, що зазвичай закінчується дуже маленькими фрагментами структурованих даних. Я вважаю за краще бачити файли в YAML, JSON, ASN.1, імені = пари значень або подібних форматах. Занадто багато синтаксису дозволяє занадто легко користувачеві зіпсувати та залишити файл у недійсному форматі.

Чи слід дотримуватися кожного системного замовчування чи мати єдине рішення?

Це повністю залежить від вас, але пам’ятайте про деякі речі:

  • Платформи на зразок * nix мають суворі обмеження, у яких місцях можна записати. Більш суворий, ніж Windows. Так:
    • Єдине місце, до якого ви повинні написати що-небудь, - це домашній каталог користувача.
    • Якщо ваша програма не є системною послугою; у цьому випадку всі файли даних, що змінюються, повинні бути записані в /var/. Nonmutable файли даних повинні зберігатися в директорії додатку в /usr/share/або /usr/local/share/або/opt/
    • Файли в /etc/не повинні ніколи бути записані додатком , коли він працює, навіть якщо він має доступ на запис до них. /etc/має бути сховищем для поведінки за замовчуванням і нічого іншого.
    • План для вашого застосування , які будуть встановлені в одному з трьох місць: /usr/local/, /opt/appnameабо /home/username/appname.
    • Краплі повинні зберігатися поряд з іншими файлами конфігурації, якщо їх потрібно змінити. Як правило, бажано використовувати формат, редагуваний користувачем, тому щось на зразок SQLite або Berkeley DB є кращим (оскільки для кожного є інструменти командного рядка), але це не обов'язково.
  • У Windows ваші програми повинні коли-небудь писати лише в каталозі користувача. Стандартизоване розташування файлів даних є Users\User\AppData. Ніде більше це не здається прийнятним.
  • На Mac OS X налаштування програми слід зберігати ~/Library/Preferencesразом з усіма списками файлів інших програм. plistздається, що це кращий формат, але ви хочете ще раз перевірити відповідність інструкцій Apple

І який найкращий портативний спосіб?

Немає "найкращого", якщо чесно. Існують лише обмеження та очікування щодо платформи. Моя рекомендація - дотримуватися конкретних платформних засобів, навіть якщо це означає писати більше коду.


1
Я думаю, що Microsoft вже кілька років відмовляє від використання реєстру - що добре. Як ви вже згадували, писати в AppData - це шлях. У .NET (можливо, також в API Windows?) Є навіть метод, який повертає правильний шлях.
MetalMikester

Також є змінна середовище:%APPDATA%
greyfade

@MetalMikester - так, абсолютно на місці. AppData підтримується роумінговим профілем і для доменного середовища.
JBRWilkinson

налаштування! = config
Yousha Aleayoub

> In my opinion, the registry was a poorly-devised system, and instead a simple text file in the Users\Username\AppData directory should be preferred. @greyfade - Довго розробник Windows API, Реймонд Чен, вирішує це і пояснює, чому використання текстових файлів через реєстр не є кращою схемою дизайну: Чому файли INI застаріли на користь реєстру
Мік

8

У Windows використовуйте %APPDATA%\appname. У розділі * NIX використовуйте ~/.appname. Не використовуйте фіксовані імена каталогів на будь-якій платформі, оскільки домашня директорія користувача може відрізнятися від стандартної (наприклад, у мережі).

Що стосується формату, використовуйте все, що вважаєте найкращим. Це рішення, яке ви можете приймати лише в контексті вашої заяви. Не зайвим і справді недоцільним є "стандартний" спосіб цього робити, якщо цей "стандартний" спосіб не є найкращим для вашої конкретної програми.

Наприклад, XML / JSON може бути хорошим способом зберігання даних / конфігурації користувачів, якщо ваша програма вже використовує XML / JSON для чогось іншого. Але якщо це простий файл конфігурації, навіщо додати додаток до вашого додатка, ввівши залежність? У цьому випадку, мабуть, найкраще просто використовувати простий текстовий файл із var: value\nрядками.

EDIT: Існує не "найкращий" портативний спосіб, оскільки для цього ОС використовують дуже різні умовні умови. Не порушуйте стандарт ОС без криваво важких причин.

EDIT2: Якщо ви налаштували загальносистемні налаштування /etcабо HKEY_LOCAL_MACHINEзапитайте себе, чи налаштування дійсно глобальне. Потім зачекайте 5 хвилин і запитайте себе знову. Якщо відповідь все-таки так, то будь-якими способами зробіть глобальну настройку. Пам'ятайте, що звичайний користувач не має доступу до запису /etcабо HKEY_LOCAL_MACHINE, роблячи це, ви гарантуєте, що хтось без прав адміністратора не може встановити ваш додаток.


Перший абзац дозволяє використовувати Path.Combine або щось подібне і, таким чином, встановити відносне розташування кореня один раз на% APPDATA% або ~, і дозволити коду робити все інше, для EDIT2 дійсно не існує кросплатформенного рішення, яке я знаю з. Можливо, є люди, які для цієї мети написали бібліотеку конверсійних платформ, принаймні, це буде приємна ідея ...
Tamara Wijsman

1
@TomWij: Безумовно, будь-який компетентний розробник повинен мати можливість зрозуміти, що вам не потрібно використовувати літерали скрізь;). Ось для чого змінні.
Chinmay Kanchi

1
~/.config/applicatonвсе більше стає кращим місцем розташування на * nix.
greyfade

@greyfade: Я ніколи насправді цього не усвідомлював, але ти маєш рацію. На моїй машині близько чверті додатків, які зберігають конфігураційні дані, ~роблять це в ~/.config/appname.
Chinmay Kanchi

Ціла купа додатків використовує ~ / .appname у Windows (що прирівнюється до вашого режиму профілю користувача, НЕ документів), і це дуже дратує. Ці папки не приховують себе!
Алан Пірс

3

Я намагаюсь триматись поза реєстром, це перестало використовувати. Я б хотів, щоб кожен хотів.

Мені подобається зберігати конфігураційні файли xml або файл bin або періодично локальну базу даних (SQLite).


+1 для збереження поза реєстром. Зараз я не можу його знайти, але, схоже, пам’ятаю, що читав, що хтось із MS визнав, що реєстр був помилкою.
Chinmay Kanchi

1
Погоджуюся з вами, крім частини XML. Я б використовував ini (або простий текстовий файл) для вимог простої настройки, а SQLite - для складних додатків.
Кодизм

Вони зараз це лише визнають? Я міг сказати тобі ще в 1995 році! Mac OS Classic це правильно зробив: папка "Налаштування", яка дає вам централізоване місце для зберігання інформації про конфігурацію, при цьому кожен додаток зберігає у своєму власному файлі. Коли я вперше побачив Реєстр, мені здалося: "Хіба Microsoft ніколи не чув, щоб не класти всі ваші яйця в один кошик?!?"
Мейсон Уілер

1
Я думаю, що як місце для розміщення налаштувань ОС (наприклад, реєстрація розширень файлів тощо) це чудово. Але якби Microsoft опублікувала це як api-повідомлення лише для читання, вони, ймовірно, поклали б на нього позов і в будь-якому разі повинні зробити його доступним для запису.
µBio

@Chinmay, @Mason, реєстр НЕ помилка, оскільки реєстр надає FAR більше, ніж просто зберігає дані конфігурації (див. Групову політику, домени, реплікацію). Помилка полягає в тому, як Microsoft поставила це розробникам, і відсутність будь-якого хорошого стандарту, як ним користуватися. Це опинилось як демпінг для даних додатків, а це не те, що колись було призначено.
Метт Оленік

3

Моя відповідь на це поєднання Chinmay Kanchi в відповідь і BioBuckyBall в відповідь .

XML / Json для простих конфігурацій, SQLite для складних, більших конфігурацій, припаркованих у папці додатків ОС за замовчуванням або папці користувача OS за замовчуванням, коли конфігурації залежать від користувача. І те й інше можна використовувати.



1

Налаштування користувача зазвичай в

/home/<user>/.<application> 

Так, наприклад, для налаштувань irssi є /home//.irssi/config


Але це конвенція Unix. Що з Windows? А в Linux, чи не затоплюється домашній каталог користувачів підкаталогами? Чому ні /home/<user>/etc/application?
Wizard79

@Lorenzo: Затоплення домашнього каталогу користувача рідко є проблемою.
Chinmay Kanchi

1
Налаштування конфігурації все частіше переміщуються до того, ~/.config/applicationщоб допомогти консолідуватись. Я схильний погодитися з цим рухом.
greyfade

1
@Lorenzo: Це точно те саме, що і Windows, що зберігає конфігураційні файли в AppData.
greyfade

1
@Chris: ніяк! :-)
Wizard79

1

Я думаю, що найкраще використовувати бажаний механізм, орієнтований на платформу. Наприклад, в OS X кращим механізмом є розміщення списку властивостей у ~ / Бібліотека / Налаштування, а API Cocoa має дійсно простий інтерфейс для зберігання та отримання налаштувань звідти.

Якщо ваша програма кросплатформна, ви можете її абстрагувати класом чи що-небудь ще.


0

Єдине, що я записую до реєстру, - це розташування програми, щоб інсталятори та оновники могли легко знайти його. Все інше зберігається у файлах у / AppData / Company / App


-2

Для програм Java я думаю, що gson - хороший вибір. Створіть об’єкти налаштувань та використовуйте gson для їх перетворення в JSON і навпаки. Має перевагу бути читабельним для людини замість якоїсь серіалізованої краплі.

Редагувати: нормально, тож, можливо, це не так загально ...


-2

Якщо ви пишете в .NET, ви можете використовувати System.Environment.SpecialFolders, щоб дізнатися, які розташування папок ви можете використовувати для збереження конфігурації чи навіть деяких даних.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.