Fichiers de configuration de l'application [fermé]

Question

OK, donc je ne veux pas déclencher une guerre sainte ici, mais nous sommes en train d'essayer de consolider la façon dont nous gérons nos fichiers de configuration d'application et nous avons du mal à prendre une décision sur la meilleure approche à adopter. .À l'heure actuelle, chaque application que nous distribuons utilise ses propres fichiers de configuration ad hoc, qu'il s'agisse de fichiers de propriétés (style ini), XML ou JSON (usage interne uniquement pour le moment !).

La plupart de notre code est Java pour le moment, nous avons donc examiné Configuration Apache Commons, mais nous l'avons trouvé assez verbeux.Nous avons également regardé Beans XML, mais cela semble être beaucoup de conneries.J'ai également l'impression d'être poussé vers le format XML, mais mes clients et mes collègues craignent d'essayer autre chose.Je peux le comprendre du point de vue du client, tout le monde a entendu parler de XML, mais en fin de compte, ne devrait-on pas utiliser le bon outil pour le travail ?

Quels formats et bibliothèques les gens utilisent-ils dans les systèmes de production de nos jours, est-ce que quelqu'un d'autre essaie d'éviter le taxe sur les équerres?

Modifier: doit vraiment être une solution multiplateforme :Linux, Windows, Solaris, etc.et le choix de la bibliothèque utilisée pour s'interfacer avec les fichiers de configuration est tout aussi important que le choix du format.

Answer 1

XML XML XML XML.Parlaient fichiers de configuration ici.Il n'y a pas de « taxe sur les équerres » si vous ne sérialisez pas d'objets dans une situation intense en performances.

Les fichiers de configuration doivent être lisibles et compréhensibles par l'homme, en plus d'être lisibles par la machine.XML est un bon compromis entre les deux.

Si votre boutique compte des gens qui ont peur de cette nouvelle technologie XML, je me sens mal pour vous.

Answer 2

YAML, pour la simple raison qu'il permet d'obtenir des fichiers de configuration très lisibles par rapport à XML.

XML :

<user id="babooey" on="cpu1">
    <firstname>Bob</firstname>
    <lastname>Abooey</lastname>
    <department>adv</department>
    <cell>555-1212</cell>
    <address password="xxxx">ahunter@example1.com</address>
    <address password="xxxx">babooey@example2.com</address>
</user>

YAML :

    babooey:
        computer : cpu1
        firstname: Bob
        lastname: Abooey
        cell: 555-1212
        addresses:
            - address: babooey@example1.com
              password: xxxx
            - address: babooey@example2.com
              password: xxxx

Les exemples ont été tirés de cette page : http://www.kuro5hin.org/story/2004/10/29/14225/062

Answer 3

D'abord:Il s’agit d’un très gros sujet de débat, pas d’un rapide questions-réponses.

Mon préféré en ce moment est simplement d'inclure Lua, parce que

• Je peux autoriser des choses comme width=height*(1+1/3)
• Je peux rendre disponibles des fonctions personnalisées
• Je peux interdire autre chose.(impossible, par exemple, Python (y compris les cornichons.))
• De toute façon, je souhaiterai probablement un langage de script ailleurs dans le projet.

Une autre option, s'il y a beaucoup de données, consiste à utiliser sqlite3, parce qu'ils ont raison de prétendre

• Petit.
• Rapide.
• Fiable.

Choisissez-en trois.

A quoi je voudrais ajouter :

• les sauvegardes sont un jeu d’enfant.(copiez simplement le fichier db.)
• plus facile de passer à une autre base de données, ODBC, peu importe.(que ce qui vient du fichier fugly)

Mais encore une fois, il s’agit d’un problème plus important.Une « grande » réponse à cette question implique probablement une sorte de matrice de fonctionnalités ou une liste de situations telles que :

Quantité de données ou durée d'exécution courte

• Pour de grandes quantités de données, vous souhaiterez peut-être un stockage efficace, comme une base de données.
• Pour de courtes séries (souvent), vous voudrez peut-être quelque chose pour lequel vous n'avez pas besoin de faire beaucoup d'analyse, pensez à quelque chose qui peut être directement inséré dans mmap:.

A quoi correspond la configuration ?

• Hôte:
  • J'aime YAML dans /etc.Est-ce réimplémenté dans Windows ?
• Utilisateur:
  • Autorisez-vous les utilisateurs à modifier la configuration avec un éditeur de texte ?
  • Doit-il être géré de manière centralisée ?Registre / gconf / base de données distante ?
  • L'utilisateur peut-il disposer de plusieurs profils?
• Projet:
  • Fichier(s) dans le répertoire du projet ?(Le contrôle de version suit généralement ce modèle...)

Complexité

• Y a-t-il seulement quelques valeurs forfaitaires ?Considérez YAML.
• Les données sont-elles imbriquées ou dépendantes d'une manière ou d'une autre ?(C'est là que ça devient intéressant.)
• Serait-il souhaitable de permettre une certaine forme de script ?
• Les modèles peuvent être considérés comme une sorte de fichiers de configuration.

Answer 4

Sans déclencher une nouvelle guerre sainte, les sentiments du post sur la « taxe à angle » sont un domaine dans lequel je pas du tout d'accord avec Jeff.Il n'y a rien de mal avec XML, il est raisonnablement lisible par l'homme (autant que les fichiers YAML, JSON ou INI le sont), mais rappelez-vous que son intention est d'être lu par des machines.La plupart des combinaisons langage/framework sont livrées avec un analyseur XML gratuit, ce qui fait de XML un très bon choix.

De plus, si vous utilisez un bon IDE comme Visual Studio, et si le XML est livré avec un schéma, vous pouvez donner le schéma à VS et comme par magie vous obtenez IntelliSense (vous pouvez en obtenir un pour NHibernate par exemple).

En fin de compte, vous devez réfléchir à la fréquence à laquelle vous allez toucher ces fichiers une fois en production, probablement pas si souvent.

Cela en dit long sur XML et pourquoi il reste un choix valable pour les fichiers de configuration (de Tim Bray):

"Si vous souhaitez fournir des données à usage général avec lesquelles le destinataire pourrait vouloir faire des choses imprévues, bizarres et folles, ou si vous voulez être vraiment paranoïaque et pointilleux à propos de i18n, ou si ce que vous envoyez ressemble plus à un document qu'à une structure, ou si l'ordre des données est important, ou si les données ont une durée de vie potentiellement longue (comme plus de quelques secondes), XML est la voie à suivre.Il me semble également que la combinaison de XML et XPath constitue un point idéal pour les formats de données qui doivent être extensibles ;c'est-à-dire qu'il est assez facile d'écrire du code de traitement XML qui n'échouera pas en présence de modifications du format du message qui ne touchent pas à l'élément qui vous intéresse.

Answer 5

@Gars

Mais la configuration de l’application n’est pas toujours constituée de paires clé/valeur.Regardez quelque chose comme la configuration de Tomcat pour savoir sur quels ports il écoute.Voici un exemple :

    <Connector port="80" maxHttpHeaderSize="8192"
           maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
           enableLookups="false" redirectPort="8443" acceptCount="100"
           connectionTimeout="20000" disableUploadTimeout="true" />


    <Connector port="8009" 
           enableLookups="false" redirectPort="8443" protocol="AJP/1.3" />

Vous pouvez avoir n'importe quel nombre de connecteurs.Définissez davantage dans le fichier et davantage de connecteurs existent.Ne définissez plus et n'existez plus.Il n'y a pas de bon moyen (à mon humble avis) de le faire avec de vieilles paires clé/valeur.

Si la configuration de votre application est simple, alors quelque chose de simple comme un fichier INI lu dans un dictionnaire conviendra probablement.Mais pour quelque chose de plus complexe comme la configuration du serveur, un fichier INI serait très difficile à maintenir, et quelque chose de plus structurel comme XML ou YAML serait préférable.Tout dépend du problème posé.

Answer 6

Nous utilisons des fichiers de configuration de style ini.Nous utilisons le Nini bibliothèque pour les gérer.Nini le rend très facile à utiliser.Nini était à l'origine pour .NET mais il a été porté sur d'autres plates-formes en utilisant Mono.

Answer 7

XML, JSON, INI.
Ils ont tous leurs forces et leurs faiblesses.
Dans un contexte applicatif, je pense que la couche d'abstraction est la chose importante.
Si vous pouvez choisir une manière de structurer les données qui constitue un bon compromis entre la lisibilité humaine et la manière dont vous souhaitez accéder/extraire les données dans le code, vous êtes en or.

Nous utilisons principalement XML là où je travaille, et je ne peux pas vraiment croire qu'un fichier de configuration chargé dans un cache en tant qu'objets lors de la première lecture ou après avoir été écrit, puis extrait du reste du programme, représente vraiment autant de choses. un impact ni sur le processeur ni sur l'espace disque.
Et il est également assez lisible, à condition que vous structurez correctement le fichier.

Et tous les langages sur toutes les plates-formes prennent en charge XML via des bibliothèques assez courantes.

Answer 8

@Herms

Ce que je voulais vraiment dire, c'était de m'en tenir à la manière recommandée par le logiciel de stocker les valeurs de configuration pour une plate-forme donnée.

Ce que vous obtenez souvent, ce sont également les manières recommandées de les modifier.Comme un menu de configuration dans un programme ou un panneau de configuration dans une application "préférences système" (pour les logiciels de services système par exemple).Ne pas laisser les utilisateurs finaux les modifier directement via RegEdit ou NotePad...

Pourquoi?

1. Les utilisateurs finaux (=clients) sont habitués à leurs plateformes
2. Le système de sauvegarde peut mieux enregistrer les "configurations sécurisées", etc.

@ninesides

À propos " choix de bibliothèque ", essayez de créer un lien (lien statique) avec n'importe quelle bibliothèque sélectionnée pour réduire le risque de vous lancer dans une guerre de conflits de versions sur les machines des utilisateurs finaux.

Answer 9

Si votre fichier de configuration est en écriture unique, en lecture seule au démarrage et que vos données sont constituées d'un ensemble de paires nom-valeur, votre meilleur choix est celui que votre développeur peut utiliser en premier.

Si vos données sont un peu plus compliquées, avec de l'imbrication, etc., vous feriez probablement mieux d'utiliser YAML, XML ou SQLite.

Si vous avez besoin de données imbriquées et/ou de la possibilité d'interroger les données de configuration après le démarrage, utilisez XML ou SQLite.Les deux disposent de très bons langages de requête (XPATH et SQL) pour les données structurées/imbriquées.

Si vos données de configuration sont hautement normalisées (par ex.5ème forme normale), vous êtes mieux avec SQLite car SQL est meilleur pour traiter des données hautement normalisées.

Si vous envisagez d'écrire dans l'ensemble de données de configuration pendant le fonctionnement du programme, il est préférable d'utiliser SQLite.Par exemple, si vous téléchargez des données de configuration à partir d'un autre ordinateur ou si vous basez vos décisions futures d'exécution d'un programme sur les données collectées lors d'une exécution précédente du programme.SQLite implémente un moteur de stockage de données très robuste qui est extrêmement difficile à corrompre en cas de panne de courant ou de programmes bloqués dans un état incohérent en raison d'erreurs.Les données corrompues entraînent des coûts de support sur le terrain élevés, et SQLite fera bien mieux que n'importe quelle solution locale ou même les bibliothèques populaires autour de XML ou YAML.

Consultez ma page pour plus d'informations sur SQLite.

Answer 10

Pour autant que je sache, le registre Windows n'est plus le moyen préféré de stocker la configuration si vous utilisez .NET - la plupart des applications utilisent désormais System.Configuration [1, 2].Comme il est également basé sur XML, il semble que tout évolue dans le sens de l'utilisation de XML pour la configuration.

Si vous souhaitez rester multiplateforme, je dirais que l'utilisation d'une sorte de fichier texte serait la meilleure voie à suivre.Quant au formatage dudit fichier, vous voudrez peut-être prendre en compte si un humain va le manipuler ou non.XML semble être un peu plus convivial pour la manipulation manuelle que les fichiers INI en raison de la structure visible du fichier.

Quant à la taxe sur les crochets angulaires, je ne m'en soucie pas trop souvent car les bibliothèques XML se chargent de l'abstraire.Le seul cas où cela peut être pris en compte est si vous disposez de très peu d’espace de stockage avec lequel travailler et que chaque octet compte.

[1] Espace de noms System.Configuration - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Utilisation des fichiers de configuration d'application dans .NET - http://www.developer.com/net/net/article.php/3396111

Answer 11

Nous utilisons des fichiers de propriétés, simplement parce que Java les prend en charge nativement.Il y a quelques mois, j'ai vu que SpringSource Application Platform utilisait JSON pour configurer son serveur et cela semblait très intéressant.je comparé diverses notations de configuration et est arrivé à la conclusion que XML semble être la meilleure solution pour le moment.Il prend en charge de bons outils et est plutôt indépendant de la plate-forme.

Answer 12

Concernant:Le commentaire d'Epatel

Je pense que la question initiale portait sur la configuration de l'application qu'un administrateur ferait, et pas seulement sur le stockage des préférences de l'utilisateur.Les suggestions que vous avez données semblent davantage concerner les préférences de l'utilisateur que la configuration de l'application, et ne sont généralement pas quelque chose que l'utilisateur traiterait directement (l'application doit fournir les options de configuration dans l'interface utilisateur, puis mettre à jour les fichiers).J'espère vraiment que vous n'obligerez jamais l'utilisateur à afficher/modifier le registre.:)

En ce qui concerne la vraie question, je dirais que XML est probablement OK, car beaucoup de gens seront habitués à l'utiliser pour la configuration.Tant que vous organisez les valeurs de configuration d'une manière facile à utiliser, la "taxe sur les équerres" ne devrait pas être trop mauvaise.

Answer 13

Peut-être un peu tangente ici, mais mon avis est que le fichier de configuration doit être lu dans un dictionnaire de valeurs clés/table de hachage lorsque l'application démarre pour la première fois et toujours accessible via cet objet à partir de là pour plus de vitesse.Généralement, la table clé/valeur commence sous forme de chaîne à chaîne, mais les fonctions d'assistance dans l'objet font des choses telles que DateTime GetConfigDate (string key) etc...

Answer 14

Je pense que la seule chose importante est de choisir un format que vous préférez et que vous puissiez naviguer rapidement.XML et JSON sont tous deux de bons formats pour les configurations et sont largement pris en charge - la mise en œuvre technique n'est pas au cœur du problème, il me semble.Il s'agit à 100 % de ce qui vous facilite la tâche des fichiers de configuration.

J'ai commencé à utiliser JSON, car je travaille beaucoup avec lui comme format de transport de données, et les sérialiseurs facilitent le chargement dans n'importe quel framework de développement.Je trouve JSON plus facile à lire que XML, ce qui rend la gestion de plusieurs services, chacun utilisant un fichier de configuration modifié assez fréquemment, d'autant plus facile pour moi !

Answer 15

Sur quelle plateforme travaillez-vous ?Je recommanderais d'essayer d'utiliser la méthode préférée/commune pour cela.

1. MacOSX - plisses
2. Win32 - Registre (ou y en a-t-il un nouveau ici, depuis longtemps que je l'ai développé)
3. Linux/Unix - ~/.apprc (nom-valeur peut-être)