fichiers de configurations de l’application

Question

OK, donc je ne veux pas commencer un saint-guerre ici, mais nous sommes dans le processus d'essayer de consolider la façon dont nous traitons nos fichiers de configuration d'application et nous avons du mal à prendre une décision sur la meilleure approche à adopter. Pour le moment, toutes les applications que nous distribuons est en utilisant son propre ad-hoc des fichiers de configuration, si c'est une propriété des fichiers (de type ini), XML ou JSON (à usage interne pour le moment!).

La plupart de nos code Java pour le moment, nous avons donc été à la recherche à la Config d'Apache Commons, mais nous avons trouvé pour être tout à fait clair. Nous avons également regardé XMLBeans, mais il semble que beaucoup de tourner en rond. J'ai aussi l'impression que si je suis poussé vers XML comme format, mais avec mes clients et mes collègues sont inquiets au sujet d'essayer quelque chose d'autre. Je peux comprendre le point de vue du client, tout le monde a entendu parler de XML, mais à la fin de la journée, ne devraient pas utiliser le bon outil pour le travail?

Quels sont les formats et les bibliothèques sont des gens en utilisant des systèmes de production de ces jours, est ce que quelqu'un d'autre en essayant d'éviter l' équerre de fixation de l'impôt?

Edit: vraiment besoin d'être une plate-forme solution: Linux, Windows, Solaris, etc. et le choix de la bibliothèque de servir d'interface avec les fichiers de configuration est tout aussi important que le choix du format

Answer 1

YAML, pour la simple raison qu'il permet des fichiers de configuration très lisibles par rapport au 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 sont tirés de cette page: http://www.kuro5hin.org/story/2004/10/29/14225/062

Answer 2

La première: C'est vraiment un grand débat problème, pas une solution Q+R.

Mon préféré pour le moment est tout simplement inclure Lua, parce que

• J'ai peut permettre des choses comme largeur=hauteur*(1+1/3)
• Je peux faire des fonctions personnalisées disponibles
• Je peux interdire quoi que ce soit d'autre. (impossible, par exemple, Python (y compris les cornichons.))
• Je vais probablement vous voulez un langage de script quelque part ailleurs dans le projet de toute façon.

Une autre option, si il y a beaucoup de données consiste à utiliser sqlite3, parce qu'elles sont en droit de réclamer

• Petite.
• Rapide.
• Fiable.

Choisissez toutes les trois.

À qui je tiens à ajouter:

• les sauvegardes sont un composant logiciel enfichable. (il suffit de copier le fichier db.)
• plus facile de passer de l'autre db, ODBC, que ce soit. (que c'est à partir de fugly-fichier)

Mais encore une fois, c'est un gros problème. Un "gros" la réponse à cette implique sans doute une sorte de fonction de la matrice ou de la liste de situations telles que:

Quantité de données, ou d'exécution court

• Pour de grandes quantités de données, vous pouvez le stockage efficace, comme un db.
• Pour les petites séries (souvent), vous pourriez voulez quelque chose que vous n'avez pas besoin de faire beaucoup d'analyse pour, envisager quelque chose qui peut être mmap:ed directement.

Quelle est la configuration se rattacher?

• Hôte:
  • J'aime YAML dans /etc. C'est que réimplémentée dans windows?
• Utilisateur:
  • Avez-vous permettre aux utilisateurs de modifier la configuration avec un éditeur de texte?
  • Devrait-il être au centre de la gérable? Registre / gconf / distance db?
  • L'utilisateur peut avoir plusieurs profils?
• Projet:
  • Fichier(s) dans le répertoire du projet? (Contrôle de Version suit généralement ce modèle...)

La complexité

• Sont là que quelques plats valeurs? Envisager YAML.
• Les données imbriquées, ou dépendant d'une certaine façon? (C'est là que ça devient intéressant.)
• Pourrait-il être une caractéristique souhaitable pour permettre une certaine forme de script?
• Les modèles peuvent être considérés comme un type de fichiers de configuration..

Answer 3

XML XML XML XML. Nous parlons des fichiers de configuration ici . Il n'y a pas de "taxe sur les cornières" si vous ne sérialisez pas d'objets dans une situation exigeante en performances.

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

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

Answer 4

Sans se lancer dans une nouvelle guerre sainte, les sentiments de l'angle du support de l'impôt' post est un domaine où j'ai totalement en désaccord avec Jeff. Il n'y a rien de mal avec XML, il est raisonnablement lisible par l'homme (autant que YAML ou JSON ou les fichiers INI sont) mais n'oubliez pas son but est d'être lu par des machines. La plupart langage/framework combos venir avec un analyseur XML, de la sorte, gratuit qui fait de XML un très bon choix.

Aussi, si vous êtes en utilisant une bonne IDE, tels que Visual Studio, et si le XML est livré avec un schéma, vous pouvez donner le schéma de VS et comme par magie, intellisense (vous pouvez en obtenir un pour NHibernate par exemple).

Ulimately vous devez penser à combien de fois vous allez être en contact avec ces fichiers une fois en production, probablement pas très souvent.

Cela dit tout cela, pour moi à propos de XML et pourquoi cela reste un choix valable pour les fichiers de configuration (à partir de Tim Bray):

"Si vous voulez fournir des données d'usage universel que le récepteur est susceptible de vouloir faire imprévus bizarre et fou les choses, ou si vous voulez être vraiment paranoïaque et pointilleux sur i18n, ou si ce que vous envoyez est plus comme un document qu'un struct, ou si l'ordre des données, des questions, ou si les données sont potentiellement de longue durée (comme dans, plus de secondes) XML est le chemin à parcourir. Il me semble aussi que la combinaison de XML et XPath frappe un sweet spot pour les formats de données qui doivent être extensible, c'est-à-dire, il est assez facile d'écrire du XML code de traitement qui ne manquera pas en présence de changements de format de message qui ne touche pas la pièce que vous aimez."

Answer 5

@Guy

Mais l'application de config n'est pas toujours juste de paires clé/valeur. Regardez quelque chose comme la configuration de tomcat pour que les ports d'é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éfinir plus dans le fichier et plus existe des connecteurs. Ne définissez pas plus et n'existe même plus. Il n'y a pas de bonne façon (à mon humble avis) pour faire ça avec un bon vieux paires clé/valeur.

Si votre application est de la config est simple, alors quelque chose de simple comme un fichier INI qui est lu dans un dictionnaire est probablement pas un problème. Mais pour quelque chose de plus complexe comme la configuration du serveur, un fichier INI serait une énorme douleur à maintenir, et quelque chose de plus structurels comme XML ou YAML serait mieux. Tout dépend du problème.