Fichiers INI ou Registre ou fichiers personnels?

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?

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é.

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?

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.

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).

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.

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.