Question

Je suis un nouveau programmeur Windows et je ne sais pas où stocker les paramètres d'application configurables par l'utilisateur.Je comprends la nécessité de fournir un moyen convivial pour l'utilisateur de modifier les paramètres de l'application, comme une modification | Paramètres de paramètres ou similaires.Mais où dois-je stocker les valeurs une fois que l'utilisateur a cliqué sur le bouton Appliquer de ce formulaire ?

Quels sont les avantages et les inconvénients du stockage des paramètres dans le registre Windows par rapport àles stocker dans un fichier INI local ou un fichier de configuration ou similaire ?

Était-ce utile?

La solution

Avantages du fichier de configuration :

  1. Facile à faire.Vous n'avez pas besoin de connaître les appels de l'API Windows.Il vous suffit de connaître l'interface d'E/S fichier de votre langage de programmation.
  2. Portable.Si vous portez votre application sur un autre système d'exploitation, vous n'avez pas besoin de modifier le format de vos paramètres.
  3. Modifiable par l'utilisateur.L'utilisateur peut modifier le fichier de configuration en dehors de l'exécution du programme.

Avantages du registre :

  1. Sécurisé.L'utilisateur ne peut pas supprimer accidentellement le fichier de configuration ou corrompre les données à moins qu'il ne connaisse regedit.Et puis l’utilisateur ne demande que des ennuis.
  2. Je ne suis pas un programmeur Windows expert, mais je suis sûr que l'utilisation du registre facilite l'exécution d'autres tâches spécifiques à Windows (paramètres spécifiques à l'utilisateur, tâches d'administration réseau comme la stratégie de groupe ou autre).

Si vous avez juste besoin d'un moyen simple de stocker les informations de configuration, je recommanderais un fichier de configuration, en utilisant INI ou XML comme format.Je suggère d'utiliser le registre uniquement si vous souhaitez retirer quelque chose de spécifique de l'utilisation du registre.

Autres conseils

Jeff Atwood a un grand article à propos du registre de Windows et pourquoi il est préférable d'utiliser les fichiers .INI à la place.

Ma vie serait bien plus facile si les paramètres par application étaient stockés dans un endroit où je pourrais facilement les voir, les manipuler et les sauvegarder.Genre, dis...dans les fichiers INI.

  • Le registre est un point de défaillance unique.C'est pourquoi chaque conseil de modification du registre que vous trouverez commence par un gros avertissement criant sur la façon dont vous pouvez casser votre ordinateur avec regedit.
  • Le registre est opaque et binaire.Même si je n'aime pas la taxe sur les crochets angulaires, au moins les fichiers de configuration XML sont raisonnablement lisibles par l'homme et autorisent autant de commentaires que bon vous semble.
  • Le registre doit être en synchronisation avec le système de fichiers.Supprimez une application sans la « désinstaller » et vous vous retrouvez avec un registre obsolète.Ou si une application a un programme de désinstallation mal écrit.Le système de fichiers n'est plus la déclaration d'enregistrement - il doit être synchronisé d'une manière ou d'une autre avec le registre.C'est une violation totale du principe DRY.
  • Le registre est monolithique.Supposons que vous vouliez déplacer une application vers un chemin différent sur votre machine, ou même vers une autre machine.Bonne chance pour extraire les paramètres pertinents pour cette application particulière à partir de l’archive tar du registre géant.Une application donnée comporte généralement des dizaines de paramètres disséminés dans tout le registre.

D'après la documentation de GetPrivateProfileString, vous devez utiliser le registre pour stocker les informations d'initialisation.

Cependant, si vous souhaitez toujours utiliser des fichiers .ini et utiliser les API de profil standard (GetPrivateProfileString, WritePrivateProfileString, etc.) pour y accéder, ils fournissent des moyens intégrés pour fournir automatiquement des « fichiers .ini virtuels » sauvegardés par le registre.Gagnant-gagnant !

Il y a une question similaire ici qui couvre certains des avantages et des inconvénients.

Je suggérerais de ne pas utiliser le registre à moins que votre application n'en ait absolument besoin.D'après ce que j'ai compris, Microsoft essaie de décourager l'utilisation du registre en raison de la flexibilité des fichiers de paramètres.De plus, je ne recommanderais pas d'utiliser des fichiers .ini, mais plutôt d'utiliser certains des fichiers fonctionnalité intégrée sur .Net pour enregistrer les paramètres utilisateur/application.

L'utilisation d'un fichier ini, dans le même répertoire que l'application, permet de le sauvegarder avec l'application.Ainsi, après avoir rechargé votre système d'exploitation, vous restaurez simplement le répertoire de l'application et vous obtenez votre configuration comme vous le souhaitez.

Il y a un autre avantage à utiliser un fichier INI par rapport au registre que je n'ai pas vu mentionné :Si l'utilisateur utilise une sorte de cryptage basé sur un volume/fichier, il peut chiffrer le fichier INI assez facilement.Avec le registre, ce sera probablement plus problématique.

Comme Daniel l'a indiqué, le stockage des données de configuration dans le registre vous donne la possibilité d'utiliser des modèles d'administration.Autrement dit, vous pouvez définir un modèle d'administration, l'utiliser dans une stratégie de groupe et administrer la configuration de votre application à l'échelle du réseau.Selon la nature de l’application, cela peut être une véritable aubaine.

Je suis d'accord avec Daniel.S'il s'agit d'une application volumineuse, je pense que je ferais des choses dans le registre.S'il s'agit d'une petite application et que vous souhaitez que certains de ses aspects soient configurables par l'utilisateur sans créer de formulaire de configuration, optez pour un fichier INI rapide.

Je fais habituellement l'analyse comme ceci (si le format du fichier .ini est option = valeur, 1 par ligne, commentaires commençant par #) :

static void Parse()
{
    StreamReader tr = new StreamReader("config.ini");
    string line;
    Dictionary<string, string> config = new Dictionary<string, string>();

    while ((line = tr.ReadLine()) != null)
    {
        // Allow for comments and empty lines.
        if (line == "" || line.StartsWith("#"))
            continue;

        string[] kvPair = line.Split('=');

        // Format must be option = value.
        if (kvPair.Length != 2)
            continue;

        // If the option already exists, it's overwritten.
        config[kvPair[0].Trim()] = kvPair[1].Trim();
    }
}

Modifier:Désolé, je pensais que vous aviez précisé la langue.L'implémentation ci-dessus est en C#.

Le registre est optimisé pour un accès rapide et une mise à jour facile, et c'est le seul moyen d'effectuer certaines tâches spécifiques à Windows, comme l'association à une extension.Et vous pouvez ignorer l'argument concernant la suppression d'un seul répertoire pour désinstaller votre programme - Windows Vista ne vous permettra pas de modifier les fichiers dans le répertoire Program Files, votre configuration devra donc de toute façon aller dans un dossier différent.

Il existe une ligne directrice générale pour la programmation Windows : faites les choses comme Microsoft attend de vous, et votre vie sera beaucoup plus facile.

Cela dit, je vois l’attrait du dossier INI, et je ne blâmerais personne de l’avoir envisagé.

Les réponses existantes couvrent beaucoup de terrain mais j'ai pensé mentionner un autre point.

J'utilise le registre pour stocker les paramètres à l'échelle du système.C'est-à-dire lorsque 2 programmes ou plus nécessitent exactement le même paramètre.Autrement dit, un cadre partagé par plusieurs programmes.

Dans tous les autres cas, j'utilise un fichier de configuration local qui se trouve soit dans le même chemin que l'exécutable, soit à un niveau inférieur (dans un répertoire de configuration).Les raisons sont déjà couvertes dans d'autres réponses (portable, peut être modifiée avec un éditeur de texte, etc.).

Pourquoi mettre les paramètres à l’échelle du système dans le registre ?Eh bien, j'ai découvert que si un paramètre est partagé mais que vous utilisez des fichiers de configuration locaux, vous finissez par dupliquer les paramètres.Cela peut signifier que vous devrez modifier un paramètre à plusieurs endroits.

Par exemple, disons que le programme A et le programme B pointent tous deux vers la même base de données.Vous pouvez avoir un paramètre de registre « à l’échelle du système » pour la chaîne de connexion.Si vous souhaitez pointer vers une autre base de données, vous pouvez modifier la chaîne de connexion à un seul endroit et les deux programmes s'exécuteront désormais sur l'autre base de données.

Remarque : il ne sert à rien d'utiliser le registre de cette manière si deux programmes ou plus n'ont pas besoin d'utiliser les mêmes valeurs.Par exemple, le programme A et le programme B nécessitent tous deux une chaîne de connexion à la base de données qui peut être le même, mais pas toujours.Par exemple, je souhaite que le programme B utilise désormais une base de données de test mais que le programme A continue à utiliser une base de données de production.

Avec l'exemple ci-dessus, certaines configurations locales pourraient remplacer les paramètres à l'échelle du système, mais cela pourrait commencer à devenir trop compliqué pour des tâches simples.

Les fichiers ini ou de configuration présentent un inconvénient: leur localisation si l'utilisateur a la possibilité de sélectionner l'emplacement d'installation du programme.

Votre application est-elle installée avec un programme d'installation, ou s'agit-il simplement de « Extraire et exécuter » ?Dans le premier cas, examinez les avantages et les inconvénients décrits ici.Mais pour extraire et exécuter, le registre est à mon avis un « interdit », car les gens s'attendent à pouvoir simplement supprimer le dossier de l'application pour se débarrasser de votre programme.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top