java - アプリケーション構成ファイル

Question

ここで聖戦を始めたくはありませんが、アプリケーション構成ファイルの処理方法を統合しようとしており、最善のアプローチを決定するのに苦労しています. . 現時点では、配布するすべてのアプリケーションは、プロパティファイル (ini スタイル)、XML、JSON (現時点では内部使用のみ!) のいずれであっても、独自のアドホック構成ファイルを使用しています。

現時点ではコードのほとんどが Java であるため、Apache Commons Configを見てきましたが、非常に冗長であることがわかりました。XMLBeansについても調べましたが、多くのことをいじっているようです。また、フォーマットとして XML を推し進められているようにも感じますが、クライアントや同僚は他のフォーマットを試すことに不安を感じています。クライアントの観点からは理解できますが、誰もが XML について聞いたことがあると思いますが、結局のところ、仕事に適したツールを使用するべきではないのでしょうか?

最近、実稼働システムで人々が使用しているフォーマットとライブラリは何ですか? 他の誰かが山括弧税を回避しようとしていますか?

編集： Linux、Windows、Solarisなど、クロスプラットフォームソリューションである必要があり、構成ファイルとのインターフェースに使用されるライブラリの選択は、フォーマットの選択と同じくらい重要です。

score 29 · Accepted Answer

YAML、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

例はこのページから取られました：http ：//www.kuro5hin.org/story/2004/10/29/14225/062

score 14 · Accepted Answer

最初に: これは非常に大きな議論の問題であり、簡単な Q&A ではありません。

私の今のお気に入りは、単純にLuaを含めることです。

width=height*(1+1/3) のようなものを許可できます
カスタム機能を利用可能にすることができます
それ以外は禁止できます。(たとえば、Python (pickles を含む) では不可能です。)
とにかく、プロジェクトのどこかにスクリプト言語が必要になるでしょう。

大量のデータがある場合の別のオプションは、sqlite3を使用することです。

小さな。
速い。
信頼性のある。

任意の 3 つを選択します。

私が追加したいのは：

バックアップは簡単です。（dbファイルをコピーするだけです。）
別のデータベース、ODBC などに簡単に切り替えることができます。（fugly-fileより）

繰り返しますが、これはより大きな問題です。これに対する「大きな」答えには、おそらく次のような機能マトリックスまたは状況のリストが含まれます。

データ量、または短い実行時間

大量のデータの場合、db などの効率的なストレージが必要になる場合があります。
短時間の実行 (多くの場合) では、多くの解析を行う必要がないものが必要になる場合があります。直接 mmap:ed できるものを検討してください。

構成は何に関係していますか?

ホスト：
- /etc の YAML が好きです。それはWindowsで再実装されていますか？
ユーザー：
- ユーザーがテキストエディターで構成を編集することを許可しますか?
- 一元管理できるようにする必要がありますか? レジストリ/gconf/リモートデータベース?
- ユーザーは複数の異なるプロファイルを持つことができますか?
計画：
- プロジェクトディレクトリ内のファイル? (通常、バージョン管理はこのモデルに従います...)

複雑

フラットな値がいくつかありますか? YAML を検討してください。
データはネストされていますか、または何らかの方法で依存していますか? （ここが面白いところです。）
なんらかの形式のスクリプトを許可することは、望ましい機能でしょうか?
テンプレートは、一種の構成ファイルとして表示できます。

score 11 · Accepted Answer

XML XMLXMLXML。ここでは設定ファイルについて話しています。パフォーマンスが高い状況でオブジェクトをシリアル化しない場合、「アングルブラケット税」はありません。

構成ファイルは、機械可読に加えて、人間が読める形式であり、人間が理解できる形式である必要があります。XMLは、この2つの間の適切な妥協点です。

あなたの店にその新しいもののXML技術を恐れている人々がいるなら、私はあなたに気分が悪い。

score 10 · Accepted Answer

新たな聖戦を開始することなく、「山形税」の投稿の感情は、私がジェフに大きく反対する領域の 1 つです。XML に問題はありません。人間が読むことはかなり可能ですが (YAML、JSON、または INI ファイルと同じくらい)、その意図は機械によって読み取られることです。ほとんどの言語/フレームワークの組み合わせには、何らかの XML パーサーが無料で付属しているため、XML は非常に優れた選択肢となっています。

また、Visual Studio のような優れた IDE を使用していて、XML にスキーマが付属している場合は、スキーマを VS に渡すと、魔法のようにインテリセンスを取得できます (たとえば、NHibernate 用に取得できます)。

最終的には、本番環境でこれらのファイルに触れる頻度を考える必要がありますが、おそらくそれほど頻繁ではありません。

これは、XMLについてのすべてと、それが構成ファイルの有効な選択である理由をすべて示しています（Tim Brayから）：

「受信者が予期せぬ奇妙でクレイジーなことをしたいかもしれない汎用データを提供したい場合、またはi18nについて本当に妄想的でうるさいことをしたい場合、または送信しているものがドキュメントよりもドキュメントに似ている場合構造体、またはデータの順序が重要である場合、またはデータが潜在的に長寿命 (数秒以上など) である場合は、XML が適しています. XML と XPath の組み合わせがヒットするようにも私には思えます.拡張可能である必要があるデータフォーマットのスイートスポットです。つまり、関心のある部分に影響を与えないメッセージフォーマットの変更が存在しても失敗しない XML 処理コードを作成するのは非常に簡単です。 "

score 5 · Accepted Answer

@男

ただし、アプリケーション構成は常にキーと値のペアだけではありません。リッスンするポートについては、Tomcat の構成などを確認してください。次に例を示します。

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

コネクタはいくつでも使用できます。ファイルにさらに定義すると、より多くのコネクタが存在します。これ以上定義しないでください。これ以上存在しません。単純な古いキーと値のペアでそれを行う良い方法 (imho) はありません。

アプリの構成が単純な場合は、辞書に読み込まれる INI ファイルのような単純なもので十分でしょう。しかし、サーバー構成のようなより複雑なものの場合、INI ファイルを維持するのは非常に面倒であり、XML や YAML のようなより構造的なものの方が適しています。それはすべて問題セットに依存します。

score 2 · Accepted Answer

XML、JSON、INI。
それらはすべて長所と短所があります。
アプリケーションのコンテキストでは、抽象化レイヤーが重要だと感じています。
人間の可読性とコード内のデータにアクセス/抽象化する方法との間の適切な中間点となるデータを構造化する方法を選択できる場合、あなたは黄金です。

私たちが仕事をしている場所では主にXMLを使用していますが、最初に読み取ったとき、または書き込み後にオブジェクトとしてキャッシュにロードされ、プログラムの残りの部分から抽象化された構成ファイルが、実際にはその多くであるとは信じられません。 CPUにもディスクスペースにもヒットしません。
また、ファイルを正しく構造化する限り、かなり読みやすくなります。

そして、すべてのプラットフォームのすべての言語は、いくつかのかなり一般的なライブラリを介してXMLをサポートしています。

score 2 · Accepted Answer

ini スタイルの構成ファイルを使用しています。Niniライブラリを使用してそれらを管理します。ニニはとても使いやすいです。Nini はもともと .NET 用でしたが、Mono を使用して他のプラットフォームに移植されました。

score 1 · Accepted Answer

@Herms

私が本当に意味したのは、ソフトウェアが特定のプラットフォームの構成値を保存するための推奨される方法に固執することでした。

その場合によく得られるのは、これらを変更する必要がある/変更できる推奨される方法でもあります。プログラムの構成メニューや「システム設定」アプリケーションの構成パネルのように（システムサービスソフトウェアの場合など）。エンドユーザーがRegEditまたはNotePadを介して直接変更できないようにする...

なんで？

エンドユーザー（=顧客）はプラットフォームに慣れています
バックアップ用のシステムは、「安全なセットアップ」などをより適切に保存できます

@ninesided

「ライブラリの選択」については、選択したライブラリをリンク（静的リンク）して、エンドユーザーのマシンでバージョン競合戦争が発生するリスクを減らしてください。

score 0 · Accepted Answer

Re：epatelのコメント

元々の質問は、ユーザー設定を保存するだけでなく、管理者が行うアプリケーション構成について尋ねていたと思います。あなたが提供した提案は、アプリケーション構成よりもユーザー設定の方が多く、通常はユーザーが直接処理するものではありません（アプリは、UIで構成オプションを提供してから、ファイルを更新する必要があります）。ユーザーがレジストリを表示/編集する必要がないことを心から願っています。:)

実際の質問については、XMLを構成に使用することに慣れている人が多いので、XMLはおそらく問題ないと思います。構成値を使いやすい方法で整理する限り、「アングルブラケット税」はそれほど悪くないはずです。

score 0 · Accepted Answer

私の知る限り、Windows レジストリは、.NET を使用している場合、構成を格納するための推奨される方法ではなくなりました。現在、ほとんどのアプリケーションは System.Configuration [1、2] を使用しています。これも XML ベースであるため、すべてが構成に XML を使用する方向に進んでいるようです。

クロスプラットフォームを維持したい場合は、ある種のテキストファイルを使用するのが最善の方法だと思います。上記のファイルのフォーマットに関しては、人間がファイルを操作するかどうかを考慮する必要があります。XML は、ファイルの構造が目に見えるため、INI ファイルよりも手動で操作しやすいようです。

山かっこ税については、XML ライブラリーがそれを抽象化するので、あまり気にしません。考慮すべき唯一のケースは、使用するストレージスペースが非常に少なく、すべてのバイトがカウントされる場合です。

[1] System.Configuration 名前空間 - http://msdn.microsoft.com/en-us/library/system.configuration.aspx

[2] .NET でのアプリケーション構成ファイルの使用 - http://www.developer.com/net/net/article.php/3396111

score 0 · Accepted Answer

プロパティファイルを使用しているのは、単に Java がプロパティファイルをネイティブにサポートしているからです。数か月前、SpringSource Application Platform が JSON を使用してサーバーを構成しているのを見ましたが、非常に興味深いようです。さまざまな構成表記法を比較した結果、現時点では XML が最適であると思われるという結論に達しました。優れたツールのサポートがあり、プラットフォームに依存しません。

score 0 · Accepted Answer

ここではちょっと関係ないかもしれませんが、私の意見では、アプリの最初の起動時に設定ファイルをキー値ディクショナリ/ハッシュテーブルに読み込み、それ以降は常にこのオブジェクトを介してアクセスして高速化する必要があります。通常、キー/値テーブルは文字列から文字列へと始まりますが、オブジェクトのヘルパー関数は DateTime GetConfigDate(string key) などを行います...

score 0 · Accepted Answer

唯一重要なことは、好みの形式を選択し、すばやくナビゲートできることだと思います。XML と JSON はどちらも構成の優れた形式であり、広くサポートされています。技術的な実装は問題の核心ではない、と私は考えています。構成ファイルのタスクを簡単にするものについては 100% です。

私は JSON をデータトランスポート形式としてかなり使用しているため、JSON の使用を開始しました。また、シリアライザーを使用すると、任意の開発フレームワークに簡単にロードできます。JSON は XML よりも読みやすいと思います。これにより、それぞれが非常に頻繁に変更される構成ファイルを使用して複数のサービスを処理できるため、はるかに簡単になります。

score -3 · Accepted Answer

どのプラットフォームで作業していますか? 優先/一般的な方法を使用することをお勧めします。

MacOSX - plists
Win32 - レジストリ (または、私が開発してから長い間、ここに新しいものがあります)
Linux/Unix - ~/.apprc (おそらく名前と値)

java - アプリケーション構成ファイル

15 に答える 15

データ量、または短い実行時間

構成は何に関係していますか?

複雑

Related

Reference