私はここ数年、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。後でこれに出くわした可能性のある人のために、この編集をここに残しておきます。