5

IOCコンテナーに入ろうとしていますが、多くのコンテナーがxml構成を使用していることに気付きました。多くの新しいテクノロジーがxml構成/プログラミングモデル（WCF、WPF、Spring.NET、Unity、Windsor）に移行している理由について誰かに教えてもらえますか？xmlは複雑な設定を指定するのに不適切な選択であるように思われ、タイプセーフでインテリセンスがあるコードで行う方がよいでしょう。一部の人がこれを議論の余地があると思うかもしれないことを私は知っていますが、他の点では非常にクールで高度なテクノロジーがxmlに依存している理由について本当に興味があります。

4

10 に答える 10

6

Unity 構成を XML に移動した理由は 1 つだけです。コードを再コンパイルせずに構成を変更できるからです。これは場合によっては非常に便利です。

于 2009-10-09T16:18:11.110 に答える
5

ものを接着したいのに、なぜハンマーの頭が鋼鉄なのか不思議に思うようなものです。

宣言型構成ファイルから実行時にアプリケーションをアセンブルすることが目標であり、DI 自体はそれを達成する手段にすぎません。

構成をコーディングできる場合、なぜ IC フレームワークを使用するのでしょうか? もう少し密結合の設計を使用して、多くの手間を省いてください。

于 2009-10-09T16:18:58.310 に答える
4

一般に、mxmissile が提案したように、IoC の流暢なインターフェイスが好きです (私は Unity を使用しています)。

これは、(Matthew Whited が指摘したように) 開発者だけが物事を変更できることを意味しますが、非開発者がアプリケーション内のあるクラスを別のクラスに置き換えることができるようにしたい頻度はどれくらいですか? そのような場合は、単純な構成ダイアログ (必要なデータ ストアに基づく) を準備し、その結果によって流暢な構成を制御できます。これにより、脆弱性とセキュリティの問題が回避されます。エンドユーザーが構成ファイルを台無しにすると、アプリケーションがクラッシュしたときに非難される可能性が高いためです。

構成を変更する主な使用例は、単体テストです。その場合、テスト中のクラスに手動で偽物を挿入するか (これは通常私が行うことです)、流暢な構成をやり直すことができます。

于 2009-10-09T17:49:56.177 に答える
3

IOCおよびその他の多くの「構成可能な」テクノロジー。

問題は、XML がドキュメントの相互運用性の標準として登場したことです。

そのため、全員が独自のフォーマットを作成する代わりに、全員が「新しい」フォーマットを採用しました。

しばらくは良かったのですが、ご指摘のとおり、最終的には面倒になりました。

コードで指定することについては、変更を有効にするためにコードを再コンパイルする必要がある場合がありますが、XML は text/plain であり、再コンパイルせずに変更できます。

新しいフォーマットが出現していますが、XML ほど影響を与えたものはありません。

于 2009-10-09T15:45:18.190 に答える
3

IoC コンテナーは、IoC 設計パターンを容易にするためのプログラムによるフレームワークではなく、非プログラム的にアプリケーションを展開/構成するためのレンダリング エンジンと見なす必要があります。

したがって、XML は主に次の 2 つの理由で使用されます。

  1. 構築手順を言語化するのではなく、構築されたアプリケーションのセマンティクスを明示的に視覚化します。
  2. 付加価値機能 (構成の表示、検証、変換、編集など) を提供する外部の異種アプリケーション間で構成コードを交換可能にするため。つまり、意図は、API 統合ではなく、データ統合を通じてコン​​テナーを開くことです。

Fluent API にはデータ モデルのスキーマ検証が欠けており、意図したデータ統合に使用するには柔軟性が非常に低く、XML 構成と比較することさえできません。

詳細については、IoC コンテナー内の XML: A Hell or a Realmを参照してください。

于 2009-10-19T20:43:19.717 に答える
2

Java の世界ではその後、アノテーションの使用によって可能性がもたらされましたが、 Google Guiceの作成者である Bob Lee のI don't get Springを読む必要があります。

編集:コメントで述べたように、 Spring で難しすぎたことに言及せずに前の投稿を引用するのは不公平です... . これで修正されました。思い出させてくれてありがとう。

于 2009-10-09T15:34:56.127 に答える
2

XML スキーマを検証して、「厳密に型指定」できるようにすることができます。非常に人気がある主な理由の 1 つは、理解が非常に簡単であることと、必要なほとんどすべてのプログラミング言語に非常に多くのパーサー フレームワークがあることです。フラット ファイル (固定幅や CSV など)、INI ファイル、JSON ファイル、または必要に応じてカスタム バイナリ形式を使用することを妨げるものは何もありません。

大規模なフレームワークのほとんどには、XML コンテンツを環境固有の複雑なオブジェクト構造に変換するための直接シリアル化メソッドがあるため、XML も人気があります。

于 2009-10-09T15:42:52.100 に答える
2

それは、.net 空間で他の誰もが行っていることだからです。それは web.config から始まり、人々はそれを拡張し始めました。しかし、これらのテクノロジのほとんどは、XML による構成とコードによる構成の両方をサポートしていると思います。主な違いは、アプリケーションの展開を担当するシステム管理者のような非コーダーが構成を変更するのが簡単であることです。それが必要な場合、私の意見では、XML は依然として実行可能なオプションです。私は、.net の世界は、すべてを XML 構成ファイルに入れるのではなく、構成よりも慣習を優先する傾向にあると考えています。

于 2009-10-09T15:41:37.890 に答える
1

xml のコード補完を使用できます。たとえば、Spring 構成ファイル用の Eclipse プラグインがあります。これは、とりわけ、ツールチップとして設定されているプロパティの javadoc を表示し、クラスパス内のクラス名の自動補完を提供し、内部で解決できなかった Bean 参照をマークします現在のファイルなど pp.

構成ファイルは、実際には DSL の形式であり、アプリケーション構成を表現するように調整されています。この仕立てにより、特定のものをより簡単に表現できます。たとえば、Java でコンポーネントを初期化するときに、適切なアプリケーションのシャットダウン (依存関係の前にコンポーネントをシャットダウンする必要がある) をどのように保証しますか? ビジネス サービス レイヤーの周りにインターセプターをどのように構成しますか?

それらが XML で行われる理由については、DSL が必要であり、XML には既存の基本的なツールチェーン (エディター、バリデーター、パーサーなど) の利点があったと思います。

于 2009-10-19T21:34:58.233 に答える
1

XML が XSLT 変換の結果であり、プレーンな IoC 構成の上にそのような方法でカスタム DSL を作成できるとは誰も言及していません。これは非常に強力なアプローチです。

于 2009-10-27T16:48:46.273 に答える