1

私はここ数年、Windsor のヘビー ユーザーです。Fluent Registration API の前は、Xml 登録と大量の AddComponent() コードを切り替えていました。かなり長い間、Fluent Registration API とインストーラーを特に喜んで使用してきました。私は次のようなさまざまな書き込みから印象を受けました。

http://docs.castleproject.org/Windsor.XML-Registration-Reference.ashx

Xml 登録のアプローチは支持されなくなっており、近い将来、非推奨としてマークされたとしても、私は驚かないでしょう。

さて、私の質問ですが、Fluent Registration API とインストーラーは、自動配線シナリオ (つまり、Windsor にオブジェクト グラフの作成方法を理解させたい場合) で問題なく動作します。自動配線は IoC のユースケースの大部分を占めていますが、自動配線ができない場合はどうでしょうか? つまり、サービスの複数の実装があり、Windsor にオブジェクト グラフの一部を構築する方法を伝える必要があります。私はこれを Xml 登録アプローチで何度も行ってきましたが、最近ではより好ましいアプローチはありますか? 将来が不確かなように見えるため、Xml登録アプローチに行くのをためらっていますが、Windsorでこれを達成する方法が他にわかりません。

私のユースケースは次のとおりです。

  • システムは、QA テストで実装を交換できる必要があります (つまり、信用調査 API に依存せずにテストしたい信用調査と不正検出処理)。
  • デプロイ時にさまざまな実装を条件付きでオンまたはオフにする必要がある、システム内のプロバイダー パターン。

これはすべて IoC に非常に適しているように思われ、すべてのビルディング ブロックが配置されていますが、Windsor で最も将来性のあるアプローチを採用していることを確認したいと考えています。

更新: 私は機能トグル アプローチが好きですが、最近、このフロントで非常に役立つ Windsor 機能を発見しました - Fallback Components。後でこれに出くわした可能性のある人のために、この編集をここに残しておきます。

4

3 に答える 3

0

Windsor での XML 構成サポートを廃止または削除する予定はありません。

はい、その通りです。多くの欠点があるため、推奨されるアプローチではありません。

XML で実行できることはすべて、コードで実行できます (逆は正しくないことに注意してください)。

また、XML は全か無かではないことに注意してください。XML での登録に頼らずに、例として示したシナリオを実現する方法はたくさんあります。

  • 機能トグル
  • 条件付きコンパイル
  • installerappSettings フラグに基づくif/else
  • 他...

過去にさまざまなプロジェクトでそれぞれを使用しました。

于 2013-06-29T00:39:24.127 に答える
0

この答えも役立つかもしれません。実行時に動的に実装を提供できます。ただし、それほど動的にする必要はないように思われ、何が起こっているのかが少しわかりにくくなります。

于 2013-06-27T15:05:57.563 に答える