Anwendungskonfigurationsdateien [geschlossen]

https://stackoverflow.com/questions/12144

08-06-2019
|

Frage

Okay, ich möchte hier keinen heiligen Krieg beginnen, aber wir sind dabei, die Art und Weise zu konsolidieren, wie wir mit unseren Anwendungskonfigurationsdateien umgehen, und wir haben Schwierigkeiten, eine Entscheidung für den besten Ansatz zu treffen .Derzeit verwendet jede von uns vertriebene Anwendung ihre eigenen Ad-hoc-Konfigurationsdateien, unabhängig davon, ob es sich um Eigenschaftendateien (INI-Stil), XML oder JSON handelt (derzeit nur für interne Verwendung!).

Der größte Teil unseres Codes ist im Moment Java, also haben wir uns das angeschaut Apache Commons-Konfiguration, aber wir fanden es ziemlich ausführlich.Wir haben auch nachgeschaut XMLBeans, aber es scheint, als wäre viel herumgefackelt.Ich habe auch das Gefühl, dass ich in Richtung XML als Format gedrängt werde, aber meine Kunden und Kollegen haben Bedenken, etwas anderes auszuprobieren.Ich kann es aus der Sicht des Kunden verstehen, jeder hat von XML gehört, aber am Ende des Tages sollte man nicht das richtige Tool für den Job verwenden?

Welche Formate und Bibliotheken heutzutage in Produktionssystemen verwendet werden, weiß niemand, der versucht, das zu vermeiden spitze Klammersteuer?

Bearbeiten: Es muss wirklich eine plattformübergreifende Lösung sein:Linux, Windows, Solaris usw.und die Wahl der Bibliothek, die als Schnittstelle zu Konfigurationsdateien verwendet wird, ist ebenso wichtig wie die Wahl des Formats.

Lösung

XML XML XML XML.Wir unterhalten uns Konfigurationsdateien hier.Es gibt keine „Spitzenklammersteuer“, wenn Sie Objekte nicht in einer leistungsintensiven Situation serialisieren.

Konfigurationsdateien müssen nicht nur maschinenlesbar, sondern auch für Menschen lesbar und verständlich sein.XML ist ein guter Kompromiss zwischen beiden.

Wenn es in Ihrem Shop Leute gibt, die Angst vor dieser neuen XML-Technologie haben, tun Sie mir leid.

Andere Tipps

YAML, aus dem einfachen Grund, dass es im Vergleich zu XML zu sehr gut lesbaren Konfigurationsdateien führt.

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

Die Beispiele stammen von dieser Seite: http://www.kuro5hin.org/story/2004/10/29/14225/062

Erste:Dies ist ein wirklich großes Debattenthema, keine schnelle Frage+Antwort.

Im Moment gefällt es mir am besten, einfach einzubinden Lua, Weil

Ich kann Dinge zulassen wie width=height*(1+1/3)
Ich kann benutzerdefinierte Funktionen zur Verfügung stellen
Alles andere kann ich verbieten.(Unmöglich zum Beispiel in Python (einschließlich Pickles.))
Ich werde wahrscheinlich sowieso irgendwo anders im Projekt eine Skriptsprache wollen.

Eine weitere Option, wenn viele Daten vorhanden sind, ist die Verwendung sqlite3, weil sie Recht haben, etwas zu behaupten

Klein.
Schnell.
Zuverlässig.

Wählen Sie drei beliebige aus.

Dazu möchte ich noch hinzufügen:

Backups sind ein Kinderspiel.(Kopieren Sie einfach die DB-Datei.)
einfacher, zu einer anderen Datenbank, ODBC, was auch immer zu wechseln.(als es von fugly-file ist)

Aber auch hier handelt es sich um ein größeres Problem.Eine „große“ Antwort darauf beinhaltet wahrscheinlich eine Art Feature-Matrix oder eine Liste von Situationen wie:

Datenmenge oder kurze Laufzeit

Für große Datenmengen benötigen Sie möglicherweise einen effizienten Speicher, z. B. eine Datenbank.
Für kurze Läufe (oft) möchten Sie möglicherweise etwas, für das Sie nicht viel analysieren müssen. Ziehen Sie etwas in Betracht, das direkt mmap:ed werden kann.

Worauf bezieht sich die Konfiguration?

Gastgeber:
- Ich mag YAML in /etc.Wird das in Windows neu implementiert?
Benutzer:
- Erlauben Sie Benutzern, die Konfiguration mit einem Texteditor zu bearbeiten?
- Soll es zentral verwaltbar sein?Registry / gconf / Remote-Datenbank?
- Möglicherweise hat der Benutzer mehrere verschiedene Profile?
Projekt:
- Datei(en) im Projektverzeichnis?(Die Versionskontrolle folgt normalerweise diesem Modell ...)

Komplexität

Gibt es nur wenige Pauschalwerte?Betrachten Sie YAML.
Sind die Daten verschachtelt oder in irgendeiner Weise abhängig?(Hier wird es interessant.)
Könnte es eine wünschenswerte Funktion sein, irgendeine Form von Skripterstellung zu ermöglichen?
Vorlagen können als eine Art Konfigurationsdateien betrachtet werden.

Ohne einen neuen Heiligen Krieg zu beginnen, sind die Gefühle des Beitrags zur „Spitzensteuer“ ein Bereich, in dem ich im Großen und Ganzen anderer Meinung mit Jeff.An XML ist nichts auszusetzen, es ist einigermaßen für Menschen lesbar (ebenso wie YAML-, JSON- oder INI-Dateien), aber denken Sie daran, dass es für das Lesen durch Maschinen gedacht ist.Die meisten Sprach-/Framework-Kombinationen verfügen über einen kostenlosen XML-Parser, was XML zu einer ziemlich guten Wahl macht.

Wenn Sie außerdem eine gute IDE wie Visual Studio verwenden und das XML ein Schema enthält, können Sie das Schema an VS übergeben und erhalten auf magische Weise Intellisense (Sie können beispielsweise eines für NHibernate erhalten).

Letztendlich müssen Sie darüber nachdenken, wie oft Sie diese Dateien einmal in der Produktion berühren werden, wahrscheinlich nicht so oft.

Das sagt für mich immer noch alles über XML und warum es immer noch eine gültige Wahl für Konfigurationsdateien ist (von Tim Bray):

„Wenn Sie allgemeine Daten bereitstellen möchten, mit denen der Empfänger möglicherweise unvorhergesehene, seltsame und verrückte Dinge tun möchte, oder wenn Sie in Bezug auf i18n wirklich paranoid und wählerisch sein möchten, oder wenn das, was Sie senden, eher einem Dokument ähnelt eine Struktur, oder wenn die Reihenfolge der Daten wichtig ist oder wenn die Daten möglicherweise langlebig sind (z. B. länger als Sekunden), ist XML der richtige Weg.Mir scheint auch, dass die Kombination von XML und XPath genau das Richtige für Datenformate ist, die erweiterbar sein müssen;Das heißt, es ist ziemlich einfach, XML-Verarbeitungscode zu schreiben, der bei Änderungen am Nachrichtenformat, die nicht den Teil betreffen, der Ihnen wichtig ist, nicht fehlschlägt.“

@Kerl

Aber die Anwendungskonfiguration besteht nicht immer nur aus Schlüssel/Wert-Paaren.Schauen Sie sich so etwas wie die Tomcat-Konfiguration an, um herauszufinden, welche Ports überwacht werden.Hier ist ein Beispiel:

    <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" />

Sie können beliebig viele Anschlüsse haben.Definieren Sie mehr in der Datei und es sind mehr Konnektoren vorhanden.Nicht mehr definieren und nicht mehr existieren.Es gibt meiner Meinung nach keine gute Möglichkeit, dies mit einfachen alten Schlüssel/Wert-Paaren zu tun.

Wenn die Konfiguration Ihrer App einfach ist, ist wahrscheinlich etwas Einfaches wie eine INI-Datei, die in ein Wörterbuch eingelesen wird, in Ordnung.Aber für etwas Komplexeres wie die Serverkonfiguration wäre die Pflege einer INI-Datei sehr aufwändig, und etwas Strukturierteres wie XML oder YAML wäre besser.Es hängt alles von der Problemstellung ab.

Wir verwenden Konfigurationsdateien im INI-Stil.Wir benutzen das Nini Bibliothek, um sie zu verwalten.Nini macht es sehr einfach zu bedienen.Nini war ursprünglich für .NET gedacht, wurde aber mithilfe von Mono auf andere Plattformen portiert.

XML, JSON, INI.
Sie alle haben ihre Stärken und Schwächen.
Im Anwendungskontext halte ich die Abstraktionsschicht für das Wichtigste.
Wenn Sie eine Methode zur Strukturierung der Daten wählen können, die einen guten Mittelweg zwischen menschlicher Lesbarkeit und der Art und Weise darstellt, wie Sie im Code auf die Daten zugreifen bzw. sie abstrahieren möchten, sind Sie goldrichtig.

Wo ich arbeite, verwenden wir hauptsächlich XML, und ich kann nicht wirklich glauben, dass eine Konfigurationsdatei, die beim ersten Lesen oder nach dem Schreiben als Objekte in einen Cache geladen und dann vom Rest des Programms abstrahiert wird, wirklich so viel davon ist ein Hit auf weder CPU noch Speicherplatz.
Und es ist auch gut lesbar, solange Sie die Datei richtig strukturieren.

Und alle Sprachen auf allen Plattformen unterstützen XML über einige ziemlich gängige Bibliotheken.

@Herms

Eigentlich wollte ich mich an die empfohlene Art und Weise halten, wie Software Konfigurationswerte für eine bestimmte Plattform speichern sollte.

Was Sie dann oft erhalten, sind auch die empfohlenen Möglichkeiten, wie diese geändert werden sollten/können.Wie ein Konfigurationsmenü in einem Programm oder ein Konfigurationsfenster in einer „Systemeinstellungen“-Anwendung (z. B. für Systemdienstsoftware).Endbenutzer dürfen sie nicht direkt über RegEdit oder NotePad ändern ...

Warum?

Die Endbenutzer (=Kunden) sind an ihre Plattformen gewöhnt
System für Backups kann „sichere Setups“ etc. besser speichern

@ninesided

Um " Wahl der Bibliothek ", versuchen Sie, eine beliebige ausgewählte Bibliothek einzubinden (statischer Link), um das Risiko eines Versionskonfliktkriegs auf Endbenutzercomputern zu verringern.

Wenn Ihre Konfigurationsdatei einmal beschreibbar und beim Booten schreibgeschützt ist und Ihre Daten aus einer Reihe von Name-Wert-Paaren bestehen, ist die beste Wahl diejenige, die Ihr Entwickler zuerst in Betrieb nehmen kann.

Wenn Ihre Daten etwas komplizierter sind, beispielsweise mit Verschachtelungen usw., sind Sie wahrscheinlich mit YAML, XML oder SQLite besser bedient.

Wenn Sie verschachtelte Daten und/oder die Möglichkeit benötigen, die Konfigurationsdaten nach dem Booten abzufragen, verwenden Sie XML oder SQLite.Beide verfügen über ziemlich gute Abfragesprachen (XPATH und SQL) für strukturierte/verschachtelte Daten.

Wenn Ihre Konfigurationsdaten stark normalisiert sind (z. B.5. Normalform) sind Sie mit SQLite besser dran, da SQL sich besser für den Umgang mit stark normalisierten Daten eignet.

Wenn Sie planen, während des Programmbetriebs in den Konfigurationsdatensatz zu schreiben, ist die Verwendung von SQLite besser geeignet.Zum Beispiel, wenn Sie Konfigurationsdaten von einem anderen Computer herunterladen oder wenn Sie zukünftige Programmausführungsentscheidungen auf Daten stützen, die bei früheren Programmausführungen gesammelt wurden.SQLite implementiert eine sehr robuste Datenspeicher-Engine, die extrem schwer zu beschädigen ist, wenn es zu Stromausfällen kommt oder Programme aufgrund von Fehlern in einem inkonsistenten Zustand hängen bleiben.Beschädigte Daten führen zu hohen Kosten für den Außendienst, und SQLite ist viel besser als jede selbst entwickelte Lösung oder sogar beliebte Bibliotheken rund um XML oder YAML.

Schauen Sie sich meine Seite an Weitere Informationen zu SQLite finden Sie hier.

Soweit ich weiß, ist die Windows-Registrierung nicht mehr die bevorzugte Methode zum Speichern von Konfigurationen, wenn Sie .NET verwenden – die meisten Anwendungen verwenden jetzt System.Configuration [1, 2].Da dies ebenfalls XML-basiert ist, scheint sich alles in Richtung der Verwendung von XML für die Konfiguration zu entwickeln.

Wenn Sie plattformübergreifend bleiben möchten, würde ich sagen, dass die Verwendung einer Art Textdatei der beste Weg wäre.Was die Formatierung dieser Datei betrifft, sollten Sie berücksichtigen, ob ein Mensch sie manipuliert oder nicht.Aufgrund der sichtbaren Struktur der Datei scheint XML etwas einfacher für die manuelle Manipulation zu sein als INI-Dateien.

Was die spitze Klammersteuer betrifft – ich mache mir darüber nicht allzu oft Sorgen, da die XML-Bibliotheken sich um die Abstraktion kümmern.Dies könnte nur dann in Betracht gezogen werden, wenn Sie nur über sehr wenig Speicherplatz verfügen und jedes Byte zählt.

[1] System.Configuration-Namespace – http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] Verwendung von Anwendungskonfigurationsdateien in .NET - http://www.developer.com/net/net/article.php/3396111

Wir verwenden Eigenschaftendateien, einfach weil Java sie nativ unterstützt.Vor ein paar Monaten habe ich gesehen, dass die SpringSource Application Platform JSON verwendet, um ihren Server zu konfigurieren, und es sieht sehr interessant aus.ICH verglich verschiedene Konfigurationsnotationen und kam zu dem Schluss, dass XML derzeit am besten zu passen scheint.Es verfügt über eine gute Werkzeugunterstützung und ist eher plattformunabhängig.

Re:Kommentar von Epatel

Ich glaube, bei der ursprünglichen Frage ging es um die Anwendungskonfiguration, die ein Administrator vornehmen würde, und nicht nur um das Speichern von Benutzereinstellungen.Die von Ihnen gemachten Vorschläge beziehen sich eher auf Benutzereinstellungen als auf die Anwendungskonfiguration und sind normalerweise nicht etwas, mit dem sich der Benutzer jemals direkt befassen würde (die App sollte die Konfigurationsoptionen in der Benutzeroberfläche bereitstellen und dann die Dateien aktualisieren).Ich hoffe wirklich, dass Sie den Benutzer niemals dazu zwingen, die Registrierung anzuzeigen/zu bearbeiten.:) :)

Was die eigentliche Frage betrifft, würde ich sagen, dass XML wahrscheinlich in Ordnung ist, da viele Leute es gewohnt sind, es für die Konfiguration zu verwenden.Solange Sie die Konfigurationswerte auf benutzerfreundliche Weise organisieren, sollte die „Spitze-Klammer-Steuer“ nicht allzu schlimm sein.

Vielleicht ein bisschen tangential hier, aber meiner Meinung nach sollte die Konfigurationsdatei beim ersten Start der App in ein Schlüsselwertwörterbuch/eine Hash-Tabelle eingelesen werden und von da an aus Geschwindigkeitsgründen immer über dieses Objekt darauf zugegriffen werden.Normalerweise beginnt die Schlüssel-/Werttabelle als Zeichenfolge für Zeichenfolge, aber Hilfsfunktionen im Objekt führen Dinge aus wie „DateTime GetConfigDate(string key)“ usw.

Ich denke, das einzig Wichtige ist, ein Format zu wählen, das man bevorzugt und in dem man sich schnell zurechtfindet.XML und JSON sind beide gute Formate für Konfigurationen und werden weithin unterstützt – die technische Implementierung ist meiner Meinung nach nicht der Kern des Problems.Es geht zu 100 % darum, was Ihnen die Aufgabe der Konfigurationsdateien erleichtert.

Ich habe angefangen, JSON zu verwenden, weil ich viel damit als Datentransportformat arbeite und die Serialisierer es einfach machen, es in jedes Entwicklungsframework zu laden.Ich finde JSON einfacher zu lesen als XML, was die Handhabung mehrerer Dienste, die jeweils eine Konfigurationsdatei verwenden, die ziemlich häufig geändert wird, für mich viel einfacher macht!

Auf welcher Plattform arbeiten Sie?Ich würde empfehlen, dafür die bevorzugte/allgemeine Methode zu verwenden.

MacOSX - Listen
Win32 - Registry (oder gibt es hier eine neue, die ich schon lange entwickelt habe)
Linux/Unix – ~/.apprc (Name-Wert vielleicht)

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow