Meilleure façon d'enregistrer les paramètres de l'application


17

Sous Windows, la méthode par défaut est le registre. Cela vous permet de différencier les paramètres à l'échelle du système et par utilisateur.

Sous Unix, vous devez utiliser des fichiers texte dans le dossier / etc pour les paramètres à l'échelle du système (quelle est la convention pour les paramètres par utilisateur?).

De nombreux nouveaux programmes (et en particulier ceux conçus pour être portables) utilisent des fichiers XML.

  • Quelle est la meilleure façon (et emplacement) de stocker des paramètres non BLOB?
  • Faut-il suivre chaque système par défaut ou avoir une solution unifiée?
  • Et quel est le meilleur moyen portable ?

Veuillez être très précis sur ce que vous entendez par «meilleur».

3
@ Thorbjørn: best adj \ ˈbest \ superlative of good
Wizard79

3
vous seriez étonné de la diversité des significations de «meilleur» sur les sites StackExchange.

Réponses:


23

Quelle est la meilleure façon (et emplacement) de stocker des paramètres non BLOB?

Sous Windows, il semble acceptable d'utiliser le registre. À mon avis, le registre était un système mal conçu, et plutôt un simple fichier texte dans le Users\Username\AppDatarépertoire devrait être préféré. C'est plus facile à sauvegarder, moins dangereux à modifier pour les utilisateurs et plus facile à nettoyer.

Sous Linux et la plupart des Unix, l'emplacement préféré est /home/user/.config/appnamepour les paramètres spécifiques à l'utilisateur et /etc/pour les paramètres globaux (à l'échelle du système). L'emplacement moins préféré (mais acceptable) pour les paramètres utilisateur est~/.appname , mais cela tombe généralement en disgrâce. Ces fichiers doivent être modifiables par l'utilisateur, donc un format lisible par l'homme est toujours préférable.

Je ne suis pas d'accord avec la plupart des gens que XML est un format acceptable pour stocker des données non blob. C'est, à mon avis, un format surmené et excessivement complexe pour ce qui finit généralement par être de très petites données structurées. Je préfère voir les fichiers en YAML, JSON, ASN.1, paires nom = valeur ou formats similaires. Avoir trop de syntaxe, il est trop facile pour un utilisateur de gâcher et de laisser le fichier dans un format non valide.

Faut-il suivre chaque système par défaut ou avoir une solution unifiée?

Cela dépend entièrement de vous, mais gardez à l'esprit certaines choses:

  • Les plates-formes comme * nix ont des limitations strictes sur les emplacements accessibles en écriture. Plus strict que Windows. Donc:
    • Le seul endroit où vous devez écrire est dans le répertoire personnel de l'utilisateur.
    • Sauf si votre application est un service système; dans ce cas, tous les fichiers de données modifiables doivent être écrits /var/. Les fichiers de données non modifiables doivent être conservés dans le répertoire de votre application dans /usr/share/ou /usr/local/share/ou/opt/
    • Les fichiers de configuration ne /etc/doivent jamais être écrits par l'application lorsqu'elle est en cours d'exécution, même si elle y a accès en écriture. /etc/devrait être le référentiel des comportements par défaut et rien d'autre.
    • Plan pour votre application à installer dans l' un des trois endroits: /usr/local/, /opt/appnameou /home/username/appname.
    • Les objets blob doivent être stockés avec d'autres fichiers de configuration s'ils doivent être modifiés. Il est généralement préférable d'utiliser un format modifiable par l'utilisateur, donc quelque chose comme SQLite ou Berkeley DB est préféré (car il existe des outils de ligne de commande pour chacun), mais pas obligatoire.
  • Sous Windows, vos applications ne doivent écrire que dans le répertoire utilisateur. L'emplacement normalisé des fichiers de données est Users\User\AppData. Nulle part ailleurs ne semble acceptable.
  • Sous Mac OS X, les paramètres de votre application doivent être stockés ~/Library/Preferencesavec tous les fichiers plist des autres applications. plistsemble être le format préféré, mais vous voudrez vérifier les directives Apple.

Et quel est le meilleur moyen portable?

Il n'y a pas de «meilleur», pour être honnête. Il n'y a que des limites et des attentes spécifiques à la plate-forme. Ma recommandation est de s'en tenir à des moyens spécifiques à la plate-forme, même si cela signifie écrire plus de code.


1
Je pense que Microsoft décourage l'utilisation du registre depuis quelques années - ce qui est bien. Écrire sur AppData, comme vous l'avez mentionné, est la voie à suivre. Dans .NET (peut-être aussi dans l'API Windows?), Il existe même une méthode qui renvoie le chemin correct.
MetalMikester

Il y a aussi une variable d'environnement:%APPDATA%
greyfade

@MetalMikester - oui, absolument parfait. AppData est également pris en charge par Roaming Profile pour un environnement de domaine.
JBRWilkinson

settings! = 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, développeur de longue date de l'API Windows, résout ce problème et explique pourquoi l'utilisation de fichiers texte sur le registre n'est pas un meilleur modèle de conception: pourquoi les fichiers INI sont-ils déconseillés au profit du registre
Mick

8

Sous Windows, utilisez %APPDATA%\appname. Sous * NIX, utilisez ~/.appname. N'utilisez pas de noms de répertoires fixes sous l'une ou l'autre des plates-formes, car le répertoire de base de l'utilisateur peut être différent du répertoire par défaut (il peut être sur le réseau, par exemple).

Quant au format, utilisez ce que vous pensez être le meilleur. C'est une décision que vous seul pouvez prendre dans le cadre de votre candidature. Il est inutile, et même déconseillé, d'avoir une manière "standard" de le faire, si cette manière "standard" n'est pas la meilleure pour votre programme particulier.

Par exemple, XML / JSON peut être un bon moyen de stocker des données / configuration utilisateur si votre application utilise déjà XML / JSON pour autre chose. Mais s'il s'agit d'un simple fichier de configuration, pourquoi ajouter un gonflement à votre application en introduisant une dépendance? Dans ce cas, il est probablement préférable d'utiliser simplement un fichier texte simple avec des var: value\nlignes.

EDIT: Il n'y a pas de "meilleur" moyen portable, car les OS utilisent des conventions très différentes pour cela. Ne cassez pas les normes du système d'exploitation sans une bonne et sanglante raison.

EDIT2: Si vous vous trouvez dans un réglage à l'échelle du système dans /etcou HKEY_LOCAL_MACHINE, demandez-vous si le réglage est vraiment global. Attendez ensuite 5 minutes et posez-vous à nouveau. Si la réponse est toujours oui, alors certainement, définissez un paramètre global. N'oubliez pas qu'un utilisateur normal n'a pas accès en écriture à /etcou HKEY_LOCAL_MACHINEet ce faisant, vous vous assurez que quelqu'un sans droits d'administrateur ne peut pas installer votre application.


Le premier paragraphe permet d'utiliser Path.Combine ou quelque chose de similaire et donc de définir l'emplacement racine relatif une fois sur% APPDATA% ou ~ et de laisser le code faire le reste, pour EDIT2, il n'existe en effet pas de solution multiplateforme que je connaisse de. Peut-être qu'il y a des gens qui ont écrit une bibliothèque de configuration multiplateforme à cet effet, ce serait au moins une bonne idée ...
Tamara Wijsman

1
@TomWij: Tout développeur compétent devrait sûrement pouvoir comprendre que vous n'avez pas besoin d'utiliser des littéraux partout;). C'est à cela que servent les variables.
Chinmay Kanchi

1
~/.config/applicatondevient de plus en plus l'emplacement préféré sur * nix.
greyfade

@greyfade: Je ne l'ai jamais réalisé, mais vous avez raison. Sur ma machine, environ un quart des applications qui stockent des données de configuration le ~font dans ~/.config/appname.
Chinmay Kanchi du

Un tas d'applications utilisent ~ / .appname dans Windows (ce qui équivaut à votre répertoire de profil utilisateur, PAS aux documents) et c'est très ennuyeux. Ces dossiers ne se cachent pas!
Alan Pearce

3

J'essaie de me tenir à l'écart du registre, c'est beaucoup trop utilisé. Je souhaite que tout le monde le fasse.

J'aime garder les fichiers de configuration xml ou un fichier bin ou parfois une base de données locale (SQLite).


+1 pour garder hors du registre. Je ne le trouve pas maintenant, mais je me souviens avoir lu que quelqu'un de MS avait admis que le registre était une erreur.
Chinmay Kanchi du

1
D'accord avec vous sauf la partie XML. J'utiliserais ini (ou un simple fichier texte) pour une configuration simple et SQLite pour des applications complexes.
Codisme

Ils l'admettent maintenant? Je pourrais vous l'avoir dit en 1995! Mac OS Classic avait raison: un dossier Préférences pour vous donner un emplacement centralisé pour stocker les informations de configuration, chaque application étant enregistrée dans son propre fichier. Quand j'ai vu le Registre pour la première fois, je me disais: "Microsoft n'a- t-il jamais entendu parler de ne pas mettre tous ses œufs dans le même panier?!?"
Mason Wheeler du

1
Je pense que comme un endroit pour mettre les paramètres du système d'exploitation (comme l'enregistrement d'extension de fichier, etc.), ça va. Mais si Microsoft l'avait publié en tant qu'API en lecture seule, ils auraient probablement été poursuivis et auraient dû le rendre accessible en écriture de toute façon.
µBio

@Chinmay, @Mason, le registre N'EST PAS une erreur car le registre fait bien plus que simplement stocker des données de configuration (voir: stratégie de groupe, domaines, réplication). L'erreur est de savoir comment Microsoft l'a présenté aux développeurs et de l'absence de bonne norme sur la façon de l'utiliser. Il a fini par devenir un dépotoir pour les données des applications, ce qui n'était pas ce à quoi il était destiné.
Matt Olenik

3

Ma réponse est une combinaison de Chinmay de Kanchi réponse et de BioBuckyBall réponse .

XML / Json pour les configurations simples, SQLite pour les configurations complexes et plus grandes parquées sur le dossier d'application du système d'exploitation par défaut ou le dossier utilisateur du système d'exploitation par défaut lorsque les configurations dépendent de l'utilisateur. Les deux pourraient être utilisés.


2

Sous Windows, je conserverais le paramètre d'application dans le AppDatadossier


1

Les paramètres utilisateur sont généralement

/home/<user>/.<application> 

Ainsi, par exemple pour les paramètres irssi sont /home//.irssi/config


Mais c'est une convention Unix. Et Windows? Et sous Linux, n'inonde pas le répertoire personnel des sous-répertoires? Pourquoi ne pas /home/<user>/etc/application?
Wizard79

@Lorenzo: L'inondation du répertoire personnel de l'utilisateur est rarement un problème.
Chinmay Kanchi du

1
Les paramètres de configuration sont de plus en plus déplacés ~/.config/applicationpour aider à garder les choses consolidées. Je suis enclin à être d'accord avec ce mouvement.
greyfade

1
@ Lorenzo: C'est exactement la même chose que la convention Windows de stockage des fichiers de configuration dans AppData.
greyfade

1
@Chris: pas question! :-)
Wizard79

1

Je pense qu'il est préférable d'utiliser le mécanisme spécifique à la plate-forme préféré. Par exemple, sous OS X, le mécanisme préféré est de placer une liste de propriétés dans ~ / Library / Preferences, et l'API Cocoa a une interface très simple pour stocker et récupérer les paramètres à partir de là.

Si votre application est multiplateforme, vous pouvez l'abstraire avec une classe ou autre chose.


0

La seule chose que j'écris dans le registre est l'emplacement de l'application, afin que les installateurs et les mises à jour puissent le trouver facilement. Tout le reste est stocké dans des fichiers dans / AppData / Company / App


-2

Pour les applications Java, je pense gson est un bon choix. Créez vos objets de paramètres et utilisez gson pour les convertir en JSON et vice versa. A l'avantage d'être lisible par l'homme au lieu d'un blob sérialisé.

Edit: ok, donc ce n'est peut-être pas si général ...


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.