Fichiers INI ou Registre ou fichiers personnels?

19

Je souhaite sauvegarder la configuration de mon projet qui comprend

  1. Taille de l'écran
  2. Position de l'écran
  3. Chemins d'accès aux dossiers
  4. Paramètres utilisateurs, etc.

Les emplacements standard où vous pouvez enregistrer ces valeurs de configuration sont:

  1. Enregistrement
  2. Fichiers INI
  3. Fichiers personnels (comme * .cfg)

Comment choisissez-vous entre ces lieux? De plus, y a-t-il des avantages et des inconvénients à utiliser l'un d'eux?

Shirish11
la source
2
Quels outils utilisez-vous? Certaines technologies sont livrées avec des outils de gestion de configuration assez intéressants.
@ Pierre303 utilise actuellement VS 2008 pour VC ++
Shirish11
Les utilisateurs devront-ils apporter des modifications?
JeffO
1
Avez-vous pensé à YAML, vous obtenez le meilleur des deux, ini et xml en.wikipedia.org/wiki/YAML
JF Dion

Réponses:

20

Y a-t-il également des avantages et des inconvénients à utiliser l'un d'eux?

Enregistrement:

  • + Relativement standard dans l'environnement Windows.
  • + Généralement un bon support des installateurs, etc.
  • - API spécifique à la plate-forme, si vous souhaitez porter votre application.
  • - Pas particulièrement lisible par l'homme.

Fichiers INI:

  • + Format simple.
  • + Portable.
  • + Lisible par l'homme.
  • - Il peut être difficile de stocker des informations plus complexes (par exemple, tout élément imbriqué à plus de deux niveaux).
  • ?Vous devrez peut-être écrire votre propre analyseur (bien que ce ne soit pas difficile) ou utiliser une bibliothèque externe comme SimpleIni (merci à Jonathan Merlet pour le commentaire).

Fichiers XML (je suppose que c'est l'option .cfg):

  • + Un format standard.
  • + Portable.
  • + Prend en charge les structures profondément imbriquées.
  • - Pas particulièrement lisible par l'homme.

Personnellement, pour les applications Windows, j'ai tendance à utiliser C # et à utiliser un fichier personnel pour l'utilisateur, stocké en XML. Je le fais généralement parce que la lisibilité humaine n'est généralement pas une priorité dans les types d'applications que j'écris (et l'application devrait avoir un éditeur de configuration, dans tous les cas), et dans l' environnement .NET , il est très facile de travailler avec XML. Je me retrouve très souvent avec un objet UserConfiguration qui est simplement sérialisé vers et à partir d'un fichier de configuration - presque aucun développement impliqué (analyse, casting de trucs), et vous avez votre configuration prête à l'emploi dans un environnement fortement typé.

Daniel B
la source
J'ai utilisé SimpleIni pour analyser les fichiers INI il y a quelque temps et cela fonctionnait bien.
Jonathan Merlet
@JonathanMerlet merci, j'ai ajouté SimpleIni au message.
Daniel B
15

J'irais avec des fichiers INI, ils sont l'option la plus conviviale pour l'homme:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

XML peut être une bonne option, mais il ne peut pas battre la simplicité et l'élégance des INI:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

Les INI sont également très bien comprises et indépendantes de la plate-forme. Il n'y a probablement pas autant d'outils disponibles pour eux que pour les fichiers XML, car qui a besoin d'un outil spécialisé pour lire et éditer un fichier INI?

yannis
la source
2
C'est drôle, mais je trouve le XML plus beau et plus facile à lire. Pour ceux qui n'aiment pas la verbosité, JSON est une alternative appropriée.
Robert Harvey
3
@RobertHarvey JSON J'aime (et utiliserais si j'avais besoin d'une imbrication plus profonde), mais XML n'est vraiment pas ma tasse de thé ...
yannis
2
XML peut être rendu plus agréable en roulant les valeurs en attributs. Par exemple,<window width="600" height="350" />
Robert Harvey
Je suis en fait surpris que personne n'ait encore mentionné YAML. Je pense que c'est une touche plus conviviale que JSON, mais assez similaire en termes de capacité et de syntaxe. Le site yaml.org fait probablement peur à quiconque ne le connaît pas déjà.
Daniel B
@DanielB Quelqu'un a mentionné YAML ;)
yannis
6

Ma préférence va aux fichiers XML. Ils sont hiérarchiques, vous pouvez les plier à votre gré de presque n'importe quelle manière imaginable, ils sont bien compris, indépendants de la plate-forme et il existe un large éventail de logiciels disponibles pour les lire et les écrire.

Robert Harvey
la source
6
Mais horriblement verbeux et ont tendance à ne pas être lisible par l'homme après tout (ne pensez pas en retrait ou gonflé au maximum avec les déclarations d'espace de noms et autres bs).
Manjabes
1
@Manjabes: caractéristiques peu susceptibles d'être significatives pour les fichiers de configuration.
Robert Harvey
@robert harvey: très important là où j'habite. Pour l'ingérence de base avec les paramètres que vous utilisez l'interface graphique, pour les paramètres avancés, vous allez modifier l'ini.
Pieter B
6

Pour élargir la suggestion de Jeff D de YAML , voici une brève introduction.

YAML est similaire à JSON (en fait, JSON est un sous-ensemble de YAML depuis la version 1.2 de la norme YAML, et peut donc être valide JSON peut être analysé par les analyseurs YAML). À première vue, la principale différence est que YAML (par défaut) utilise l'indentation plutôt que le bracketing pour afficher la hiérarchie. Il existe également un manque notable de guillemets pour les chaînes. Un exemple rapide d'en haut:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

Voir la page YAML de Wikipedia pour de meilleurs exemples. La prise en charge de YAML existe pour la plupart des langues principales (voir yaml.org pour plus de détails).

Daniel B
la source
3

Vous avez oublié une option: la base de données. Ceci est principalement utilisé dans les scénarios où des utilisateurs se connectent à votre application lorsque votre application ne peut pas compter sur l'utilisateur Windows connecté. C'est par exemple lorsque votre application s'exécute dans une fenêtre en mode kiosque.

Pieter B
la source
Vous aurez peut-être besoin d'un fichier INI ou d'une clé de registre pour conserver les détails / la chaîne de connexion à la base de données
Class Skeleton
@CamelCase Inifile ou clé de registre a déjà été mentionné dans la question, mais pas dans la base de données. Je ne voulais pas dire que vous ne pouvez pas utiliser plusieurs méthodes en même temps.
Pieter B
1

Ma préférence personnelle est les fichiers XML:

Dans la plupart des cas, je ne m'attends pas à ce que l'utilisateur doive modifier ses paramètres de configuration, donc le problème de lisibilité humaine n'est pas un argument dans ce cas.

S'ils ont besoin de les modifier, vous pouvez fournir un outil d'édition - cela empêche l'utilisateur de faire quelque chose de stupide avec les données. S'ils veulent restaurer les paramètres par défaut, vous pouvez simplement leur dire de supprimer le fichier x, ce que la plupart des utilisateurs seront à l'aise de faire.

Notez que vous devez toujours faire attention à ce que vous soyez autorisé à stocker votre fichier car certains emplacements n'ont pas d'accès en écriture par défaut dans Windows 7, etc.


Les fichiers INI sont un bon moyen standard de stocker la configuration et sont testés et éprouvés, mais ils me semblent un peu «Windows 3.1»!

Probablement la meilleure option si vous voulez que l'utilisateur puisse bricoler ses données


Je m'éloignerais personnellement du registre. D'une part, vous ne pouvez pas garantir que l'utilisateur dispose des autorisations nécessaires pour lire / écrire là où vous souhaitez stocker vos données.

Dans les systèmes d'exploitation plus récents où la virtualisation du registre entre en jeu, cela peut provoquer une grande confusion car vous ne pouvez pas `` voir '' les paramètres virtualisés - cela nous a mordu plus d'une fois où nous avons passé des heures à essayer de comprendre pourquoi quelque chose ne fonctionnait pas.

Matt Wilko
la source
3
Si vous vous inquiétez des autorisations pour les emplacements de registre, vous essayez probablement de les stocker au mauvais endroit. L'utilisateur doit avoir des autorisations sur la ruche HKey_Current_User, et c'est là que les paramètres par utilisateur doivent être!
Neil White
@NeilWhite - a convenu qu'ils devraient avoir des autorisations mais un administrateur informatique trop zélé peut changer cela (ou donner des autorisations de lecture / écriture mais pas de création). L'OP n'a pas non plus mentionné que ces paramètres étaient nécessairement par utilisateur , ils peuvent être par machine.
Matt Wilko
En outre, le registre peut avoir une limite de taille. Les fichiers ne le font pas.
Linquize