Лучший способ сохранить настройки приложения

17

В Windows по умолчанию используется реестр. Это позволяет вам различать общесистемные и индивидуальные настройки.

В Unix вы должны использовать текстовые файлы в папке / etc для общесистемных настроек (что является соглашением для настроек для каждого пользователя?).

Многие новые программы (особенно разработанные для переносимости) используют файлы XML.

Каков наилучший способ (и местоположение) для хранения настроек, отличных от BLOB?
Должны ли мы следовать каждой системе по умолчанию или иметь единое решение?
И какой самый лучший портативный способ?

portability

— Wizard79
источник

Пожалуйста, будьте очень конкретны в отношении того, что вы имеете в виду под «лучшим».

3

@ Thorbjørn: лучший прил \ лучшее \ превосходной степени добра

— 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.
- BLOB-объекты должны храниться вместе с другими файлами конфигурации, если они должны быть изменены. Как правило, предпочтительнее использовать формат, редактируемый пользователем, поэтому предпочтительнее использовать что-то вроде SQLite или Berkeley DB (поскольку для каждого есть инструменты командной строки), но это не обязательно.
В Windows ваши приложения должны когда-либо писать только в каталоге пользователя. Стандартное расположение для файлов данных Users\User\AppData. Нигде больше не кажется приемлемым.
В Mac OS X настройки вашего приложения должны храниться ~/Library/Preferencesвместе со всеми списками файлов других приложений. plistкажется предпочтительным форматом, но вы должны перепроверить с рекомендациями Apple.

И какой самый лучший портативный способ?

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

— greyfade
источник

1

Я думаю, что Microsoft препятствует использованию реестра в течение нескольких лет - и это хорошо. Как вы упомянули, запись в AppData - это путь. В .NET (может быть, также в Windows API?) Есть даже метод, который возвращает правильный путь.

— MetalMikester

Также есть переменная окружения:%APPDATA%

— greyfade

@MetalMikester - да, абсолютно точно. AppData поддерживается перемещаемым профилем и для доменной среды.

— JBRWilkinson

настройки! =

— конфиг

> 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, Раймонд Чен (Raymond Chen), решает эту проблему и объясняет, почему использование текстовых файлов через реестр не является лучшим шаблоном проектирования: почему файлы INI не рекомендуются в пользу реестра

— Мик

8

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

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

Например, XML / JSON может быть хорошим способом хранения пользовательских данных / конфигурации, если ваше приложение уже использует XML / JSON для чего-то другого. Но если это простой файл конфигурации, зачем добавлять раздув в свое приложение, вводя зависимость? В этом случае, вероятно, лучше всего использовать простой текстовый файл со var: value\nстроками.

РЕДАКТИРОВАТЬ: Существует не «лучший» портативный способ, так как ОС используют для этого очень разные соглашения. Не нарушайте стандарты ОС без кровавой причины.

РЕДАКТИРОВАТЬ 2: Если вы обнаружите, что устанавливаете общесистемную настройку в /etcили HKEY_LOCAL_MACHINE, спросите себя, действительно ли настройка глобальна. Затем подождите 5 минут и спросите себя снова. Если ответ все еще положительный, то непременно сделайте глобальную настройку. Помните, что обычный пользователь не имеет права на запись /etcили HKEY_LOCAL_MACHINE, делая это, вы гарантируете, что кто-то без прав администратора не сможет установить ваше приложение.

— Чинмай Канчи
источник

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

— Тамара Вийсман

1

@ TomWij: Конечно, любой компетентный разработчик должен понять, что вам не нужно везде использовать литералы;). Вот для чего переменные.

— Чинмай Канчи

1

~/.config/applicatonстановится все более предпочтительным местом для * nix.

— Greyfade

@greyfade: Я никогда не осознавал этого, но ты прав. На моей машине около четверти приложений, в которых хранятся данные конфигурации, ~делают это ~/.config/appname.

— Чинмай Канчи

Целая куча приложений использует ~ / .appname в Windows (что соответствует каталогу вашего профиля пользователя, а НЕ документам), и это очень раздражает. Эти папки не прячутся!

— Алан Пирс

3

Я стараюсь держать из реестра, это способ более использоваться. Я хотел бы, чтобы все.

Мне нравится хранить XML-файлы конфигурации или bin-файл или иногда локальную базу данных (SQLite).

— μBio
источник

+1 за хранение вне реестра. Я не могу найти его сейчас, но, кажется, помню, что читал, что кто-то из MS признал, что реестр был ошибкой.

— Чинмай Канчи

1

Согласен с вами, кроме части XML. Я бы использовал ini (или простой текстовый файл) для простых требований настройки и SQLite для сложных приложений.

— Кодизм

Они сейчас это признают? Я мог бы сказать вам это в далеком 1995 году! Mac OS Classic поняла это правильно: папка Preferences, предоставляющая вам централизованное место для хранения информации о конфигурации, при этом каждое приложение сохраняется в своем собственном файле. Когда я впервые увидел Реестр, я сказал: «Разве Microsoft никогда не слышала о том, чтобы не класть все яйца в одну корзину?!?»

— Мейсон Уилер

1

Я думаю, что в качестве места для установки параметров ОС (например, регистрация расширения файла и т. Д.), Это хорошо. Но если бы Microsoft опубликовала его как API-интерфейс только для чтения, им, вероятно, было бы предъявлено иск за него, и в любом случае ему пришлось бы сделать его доступным для записи.

— µBio

@Chinmay, @Mason, реестр НЕ является ошибкой, потому что реестр делает FAR больше, чем просто хранит данные конфигурации (см .: групповая политика, домены, репликация). Ошибка в том, что Microsoft предоставила это разработчикам, и отсутствие какого-либо хорошего стандарта, как его использовать. Он оказался местом сброса данных приложения, а это не то, для чего он был предназначен.

— Мэтт Оленик

3

Мой ответ на это сочетание Chinmay Kanchi в ответ и BioBuckyBall в ответ .

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

— Maniero
источник

2

В Windows я бы оставил настройки приложения в AppDataпапке

— Гравитон
источник

1

Пользовательские настройки обычно находятся в

/home/<user>/.<application>

Так, например, для настроек irssi это /home//.irssi/config

— Крис
источник

Но это соглашение Unix. А как насчет Windows? А в Linux не заполняет домашний каталог пользователя подкаталогами? Почему нет /home/<user>/etc/application?

— Wizard79

@Lorenzo: Затопление домашнего каталога пользователя редко является проблемой.

— Чинмай Канчи

1

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

— Greyfade

1

@Lorenzo: Это то же самое, что и соглашение Windows о хранении файлов конфигурации в AppData.

— Greyfade

1

@ Крис: ни за что! :-)

— Wizard79

1

Я думаю, что лучше использовать предпочтительный механизм для конкретной платформы. Например, в OS X предпочтительным механизмом является размещение списка свойств в ~ / Library / Preferences, а API-интерфейс Cocoa имеет действительно простой интерфейс для хранения и извлечения настроек из него.

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

— mipadi
источник

0

Единственное, что я пишу в реестр, - это местоположение приложения, чтобы установщики и программы обновления могли легко его найти. Все остальное хранится в файлах в / AppData / Company / App

— GrandmasterB
источник

-2

Для Java - приложений я думаю gson выбор хороший. Создайте объекты настроек и используйте gson для преобразования их в JSON и наоборот. Преимущество в том, что он читается человеком, а не сериализованным блобом.

Изменить: хорошо, так что, может быть, не так широко ...

— FeatureCreep
источник

-2

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

— Джеймс
источник