IOCコンテナなどを介して依存性注入バインディングを作成するための2つの一般的なメカニズムは、XML構成または命令型コードのブロックからのものです。これらの場合、キーと値のペアは明示的です（つまり、キー=要求されたタイプ、値=返されたタイプ）。
それでも、アプリケーション/ IOCコンテナに[IMyClass]キーのみが与えられ、コンテナが一連のアプリケーションアセンブリの依存関係を反映して、名前が一致するすべての具象クラス[MyClass]を見つける3番目の「ヒューリスティック」アプローチがあります。言い換えると、「リターンタイプ」の値は、宣言されるのではなく検出されます。
私が知りたいのは2つあります。
これは、コンベンションベースの構成または自動登録と呼ばれ、次の.NETDIコンテナでサポートされています。
DIコンテナに使用される最も一般的な構成メカニズムは次のとおりです。
4番目の、しかし一般的ではないアプローチは、属性を使用することです。Managed Extensibility Frameworkは、このアプローチの最も顕著な例であり、Javaでより一般的です。
あなたが「ヒューリスティック」アプローチと呼ぶものは、私がコンベンションと呼ぶものです。ほとんどのIoCコンテナでは、バインディングの解決方法をオーバーライドできます。つまり、必要な規則を導入できます。私が知っているそのようなデフォルトの規則はありません。むしろ、ほとんどのコンテナはデフォルトとして何もしません。構成ファイルまたはコードを使用して、型を解決する方法を教えるのはあなたの仕事です。
私が見つけたカスタム規則の例はかなり一般的であり、多くの宣言を節約できます。要求された型が「I」で始まり「Service」で終わるインターフェース型である場合は、同じ名前の型を作成して解決しようとします「私」は別として。これにより、名前IFooServiceがFooService自動的に解決されます。さらに、さまざまなコンテキストでさまざまなサービスを決定するロジックをかなり簡単に導入でき、サービスインスタンスの存続期間を共通の場所で処理できます。
ほとんどのIoCコンテナのバインド方法をオーバーライドできるため、他の動作を導入することもできます。ただし、一般的に、実際には2つのオプションがあります。
私は通常、あなたが構成のカスタムステップとして説明することを行いました。AFAIKには、そのような戦略をすぐに提供するコンテナはありません（私の意見では、コンテナの一部ではなく、コンテナの責任の外部にあるべき構成要素です）。
私はStructureMapをかなり使用しているので、そのコンテナーでそのようなことを行う方法を知っています。それは基本的にカスタム登録規則です（初期化またはレジストリから、Scan-lambdaブロックに移動し、「規則」を見つけます。 " 方法）。
これにより、反映されたタイプを確認し、適切と思われるようにそれらをコンテナー構成に挿入できます。それはあなたがやろうとしていることを可能にするはずです。