Najlepszy sposób na zapisanie ustawień aplikacji

17

W systemie Windows domyślnym sposobem jest rejestr. Pozwala to na rozróżnienie ustawień systemowych i poszczególnych użytkowników.

W Uniksie powinieneś używać plików tekstowych w folderze / etc dla ustawień systemowych (jaka jest konwencja dla ustawień dla poszczególnych użytkowników?).

Wiele nowych programów (a zwłaszcza tych przeznaczonych do przenośności) korzysta z plików XML.

  • Jaki jest najlepszy sposób (i lokalizacja) do przechowywania ustawień innych niż BLOB?
  • Czy powinniśmy stosować domyślne ustawienia każdego systemu, czy mieć ujednolicone rozwiązanie?
  • A jaki jest najlepszy przenośny sposób?
Wizard79
źródło
Prosimy o sprecyzowanie, co masz na myśli przez „najlepszy”.
3
@ Thorbjørn: best przym \ ˈbest \ superlative of good
Wizard79
3
byłbyś zaskoczony różnorodnością znaczeń „najlepszy” na stronach StackExchange.

Odpowiedzi:

23

Jaki jest najlepszy sposób (i lokalizacja) do przechowywania ustawień innych niż BLOB?

W systemie Windows korzystanie z rejestru wydaje się dopuszczalne. Moim zdaniem rejestr był źle opracowanym systemem i zamiast tego Users\Username\AppDatapowinien być preferowany prosty plik tekstowy w katalogu. Jest to łatwiejsze do tworzenia kopii zapasowych, mniej niebezpieczne dla użytkowników do modyfikacji i łatwiejsze do czyszczenia.

W systemie Linux i większości systemów uniksowych preferowaną lokalizacją są /home/user/.config/appnameustawienia specyficzne dla użytkownika i ustawienia /etc/globalne (systemowe). Mniej preferowana (ale akceptowalna) lokalizacja dla ustawień użytkownika to ~/.appname, ale generalnie nie jest to przychylne. Pliki te powinny być edytowalne przez użytkownika, dlatego zawsze preferowany jest format czytelny dla człowieka.

Nie zgadzam się z większością osób, że XML jest akceptowalnym formatem do przechowywania danych niepobranych. Moim zdaniem jest to przesadny i nadmiernie złożony format, który zwykle kończy się na bardzo małych fragmentach ustrukturyzowanych danych. Wolę widzieć pliki w YAML, JSON, ASN.1, pary nazwa = wartość lub podobne formaty. Zbyt duża składnia sprawia, że ​​użytkownikowi zbyt łatwo jest zepsuć się i pozostawić plik w niepoprawnym formacie.

Czy powinniśmy stosować domyślne ustawienia każdego systemu, czy mieć ujednolicone rozwiązanie?

To zależy wyłącznie od Ciebie, ale pamiętaj o kilku rzeczach:

  • Platformy takie jak * nix mają ścisłe ograniczenia dotyczące możliwości zapisywania lokalizacji. Bardziej rygorystyczny niż Windows. Więc:
    • Jedynym miejscem, w którym powinieneś napisać na cokolwiek, jest katalog domowy użytkownika.
    • Chyba że twoja aplikacja jest usługą systemową; w takim przypadku wszystkie zmienne pliki danych powinny zostać zapisane /var/. Nonmutable pliki danych powinny być przechowywane w katalogu app w /usr/share/lub /usr/local/share/lub/opt/
    • Pliki konfiguracyjne nigdy nie/etc/ powinny być zapisywane przez aplikację podczas działania, nawet jeśli ma do nich dostęp do zapisu. powinno być repozytorium domyślnych zachowań i nic więcej./etc/
    • Plan dla aplikacji do zainstalowania w jednym z trzech miejsc: /usr/local/, /opt/appname, lub /home/username/appname.
    • Obiekty BLOB powinny być przechowywane wraz z innymi plikami konfiguracyjnymi, jeśli mają zostać zmienione. Jest to generalnie korzystne , aby użyć formatu użytkownika można edytować, więc preferowane coś jak SQLite lub Berkeley DB (ponieważ istnieją narzędzia wiersza polecenia dla każdego), ale nie wymagane.
  • W systemie Windows aplikacje powinny zapisywać tylko w katalogu użytkownika. Standardowa lokalizacja plików danych to Users\User\AppData. Nigdzie indziej nie wydaje się do przyjęcia.
  • W systemie Mac OS X ustawienia aplikacji powinny być przechowywane ~/Library/Preferenceswraz ze wszystkimi listami plików innych aplikacji. plistwydaje się być preferowanym formatem, ale warto dwukrotnie sprawdzić wytyczne Apple.

A jaki jest najlepszy przenośny sposób?

Szczerze mówiąc, nie ma „najlepszego”. Istnieją tylko specyficzne dla platformy ograniczenia i oczekiwania. Radzę trzymać się środków specyficznych dla platformy, nawet jeśli oznacza to pisanie większej ilości kodu.

greyfade
źródło
1
Myślę, że Microsoft od kilku lat zniechęca do korzystania z rejestru - co jest dobre. Jak już wspomniałeś, pisanie do AppData jest dobrym rozwiązaniem. W .NET (może także w Windows API?) Istnieje nawet metoda, która zwraca prawidłową ścieżkę.
MetalMikester
Istnieje również zmienna środowiskowa:%APPDATA%
greyfade 10.10.10
@MetalMikester - tak, absolutnie na miejscu. AppData jest obsługiwany również przez profil mobilny dla środowiska domeny.
JBRWilkinson,
ustawienia! = 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 - Raymond Chen, wieloletni programista Windows API, rozwiązuje ten problem i wyjaśnia, dlaczego używanie plików tekstowych w rejestrze nie jest lepszym wzorcem projektowym: Dlaczego pliki INI są przestarzałe na rzecz rejestru
Mick
8

W systemie Windows użyj %APPDATA%\appname. W obszarze * NIX użyj ~/.appname. Nie używaj ustalonych nazw katalogów na żadnej platformie, ponieważ katalog domowy użytkownika może różnić się od domyślnego (na przykład w sieci).

Jeśli chodzi o format, użyj tego, co uważasz za najlepsze. Jest to decyzja, którą tylko Ty możesz podjąć w kontekście swojej aplikacji. Nie ma potrzeby, a wręcz nie jest wskazane, aby mieć „standardowy” sposób na zrobienie tego, jeśli ten „standardowy” sposób nie jest najlepszy dla danego programu.

Na przykład XML / JSON może być dobrym sposobem na przechowywanie danych / konfiguracji użytkownika, jeśli twoja aplikacja już używa XML / JSON do czegoś innego. Ale jeśli jest to prosty plik konfiguracyjny, po co dodawać wzdęcia do swojej aplikacji, wprowadzając zależność? W takim przypadku najlepiej jest po prostu użyć prostego pliku tekstowego z var: value\nliniami.

EDYCJA: Nie ma „najlepszego” przenośnego sposobu, ponieważ systemy operacyjne używają do tego bardzo różnych konwencji. Nie łam standardów systemu operacyjnego bez cholernie dobrego powodu.

EDYCJA 2: Jeśli wybierzesz ustawienie systemowe dla /etclub HKEY_LOCAL_MACHINE, zapytaj siebie, czy ustawienie jest naprawdę globalne. Następnie odczekaj 5 minut i ponownie zadaj sobie pytanie. Jeśli odpowiedź nadal brzmi „tak”, to z całą pewnością dokonaj globalnego ustawienia. Pamiętaj, że zwykły użytkownik nie ma dostępu do zapisu /etclub HKEY_LOCAL_MACHINE, robiąc to, masz pewność, że osoba bez uprawnień administratora nie będzie mogła zainstalować Twojej aplikacji.

Chinmay Kanchi
źródło
Pierwszy akapit pozwala użyć Path.Combine lub czegoś podobnego, a tym samym raz ustawić względną lokalizację katalogu głównego na% APPDATA% lub ~ i pozwolić kodowi zrobić resztę, dla EDIT2 naprawdę nie istnieje rozwiązanie wieloplatformowe, które znam z. Być może są ludzie, którzy napisali w tym celu wieloplatformową bibliotekę konfiguracji, to byłby przynajmniej fajny pomysł ...
Tamara Wijsman
1
@TomWij: Z pewnością każdy kompetentny programista powinien wiedzieć, że nie trzeba wszędzie używać literałów;). Po to są zmienne.
Chinmay Kanchi,
1
~/.config/applicatonstaje się coraz bardziej preferowaną lokalizacją na * nix.
greyfade
@greyfade: Nigdy nie zdawałem sobie z tego sprawy, ale masz rację. Na moim komputerze ~robi to około jedna czwarta aplikacji przechowujących dane konfiguracyjne ~/.config/appname.
Chinmay Kanchi,
Cała gama aplikacji używa ~ / .appname w systemie Windows (co odpowiada katalogowi profilu użytkownika, NIE dokumentom) i jest to bardzo denerwujące. Te foldery się nie chowają!
Alan Pearce
3

Staram się trzymać z rejestru, to jest sposób na używane. Chciałbym, żeby wszyscy to zrobili.

Lubię przechowywać pliki konfiguracyjne xml, plik bin lub czasami lokalną bazę danych (SQLite).

µBio
źródło
+1 za trzymanie poza rejestrem. Nie mogę go teraz znaleźć, ale wydaje mi się, że pamiętam, że ktoś ze stwardnienia rozsianego przyznał, że rejestr był błędem.
Chinmay Kanchi,
1
Zgadzam się z tobą, z wyjątkiem części XML. Używałbym ini (lub zwykłego pliku tekstowego) dla prostych wymagań ustawień i SQLite dla złożonych aplikacji.
Codism
Dopiero teraz to przyznają? Mógłbym ci to powiedzieć w 1995 roku! Mac OS Classic ma rację: folder Preferencje zapewniający scentralizowane miejsce do przechowywania informacji o konfiguracji, a każda aplikacja jest zapisywana we własnym pliku. Kiedy po raz pierwszy zobaczyłem Rejestr, pomyślałem: „Czy Microsoft nigdy nie słyszał, aby nie wkładać wszystkich jajek do jednego koszyka?!?”
Mason Wheeler,
1
Myślę, że jako miejsce do wprowadzania ustawień systemu operacyjnego (takich jak rejestracja rozszerzenia pliku itp.), Jest w porządku. Ale jeśli Microsoft opublikowałby go jako interfejs tylko do odczytu, prawdopodobnie zostałby o niego pozwany i i tak musiałby go zapisać.
µBio
@Chinmay, @Mason, rejestr NIE jest pomyłką, ponieważ rejestr FAR nie tylko przechowuje dane konfiguracyjne (patrz: zasady grupy, domeny, replikacja). Błąd polega na tym, jak Microsoft przekazał go programistom, oraz na braku dobrego standardu korzystania z niego. Skończyło się to na wysypisku danych aplikacji, co nie jest do tego przeznaczone.
Matt Olenik,
3

Moja odpowiedź jest kombinacją Chinmay Kańczi za odpowiedź i BioBuckyBall za odpowiedź .

XML / Json dla prostych konfiguracji, SQLite dla złożonych, większe konfiguracje zaparkowane w domyślnym folderze aplikacji systemu operacyjnego lub domyślnym folderze użytkownika systemu operacyjnego, gdy konfiguracje zależą od użytkownika. Oba mogą być użyte.

Maniero
źródło
2

W systemie Windows zachowałbym ustawienie aplikacji w AppDatafolderze

Grawiton
źródło
1

Ustawienia użytkownika są zwykle w

/home/<user>/.<application> 

Na przykład ustawienia irssi to /home//.irssi/config

Chris
źródło
Ale to konwencja uniksowa. Co z Windows? A w Linuksie nie zalewa katalogów domowych użytkowników podkatalogami? Dlaczego nie /home/<user>/etc/application?
Wizard79
@Lorenzo: Zalanie katalogu domowego użytkownika rzadko stanowi problem.
Chinmay Kanchi,
1
Ustawienia konfiguracji są coraz częściej przenoszone, ~/.config/applicationaby pomóc w utrzymaniu konsolidacji. Jestem skłonny zgodzić się z tym ruchem.
greyfade
1
@Lorenzo: Jest to dokładnie to samo, co konwencja Windows dotycząca przechowywania plików konfiguracyjnych AppData.
greyfade
1
@Chris: nie ma mowy! :-)
Wizard79
1

Myślę, że najlepiej jest użyć preferowanego mechanizmu specyficznego dla platformy. Na przykład w OS X preferowanym mechanizmem jest umieszczenie listy właściwości w ~ / Library / Preferences, a interfejs API Cocoa ma naprawdę prosty interfejs do przechowywania i pobierania ustawień z tego miejsca.

Jeśli Twoja aplikacja jest wieloplatformowa, możesz ją wyodrębnić za pomocą klasy lub czegoś innego.

mipadi
źródło
0

Jedyne, co piszę do rejestru, to lokalizacja aplikacji, aby instalatorzy i aktualizatorzy mogli ją łatwo znaleźć. Cała reszta jest przechowywana w plikach w / AppData / Company / App

Grandmaster B.
źródło
-2

W przypadku aplikacji Java myślę, że gson to dobry wybór. Utwórz obiekty ustawień i użyj gson, aby przekonwertować je na JSON i odwrotnie. Ma tę zaletę, że jest czytelny dla człowieka zamiast zserializowanego obiektu blob.

Edycja: ok, więc może nie jest tak ogólna ...

FeatureCreep
źródło
-2

Jeśli piszesz w .NET, możesz użyć System.Environment.SpecialFolders, aby dowiedzieć się, jakich lokalizacji folderów możesz użyć do zapisania konfiguracji, a nawet niektórych danych.

James
źródło