私はここで議論に関する他のさまざまな質問を読みました、特に特に
Ioc / DI-エントリアプリケーションですべてのレイヤー/アセンブリを参照する必要があるのはなぜですか?
そしてこの記事(そして他の様々な資料)。
ただし、ライブラリ(DLL).NETプロジェクトのどこにコンポジションルートを配置するかはわかりません。プロジェクトは、記事に記載されている特定のタイプに属していません。デスクトップ、コンソール、さらにはWebアプリケーションでも、この点は代わりに明確に定義されています。
私の現在のアプローチは、コンテナーをラップし、タイプを登録し、Resolveメソッドを再公開することです。
class DefaultBootstrapper : IBootstrapper {
public Bootstrapper() {
_container = new XXXContainer();
RegisterTypes(_container);
}
public T Resolve<T>() where T : class {
return _container.Resolve<T>();
}
// + other _container.Resolve() overloads
private readonly XXXContainer _container;
}
次に、ライブラリのコンシューマーがライブラリのルートインスタンスを作成するのを防ぎ(たとえば、内部コンストラクターの定義)、シングルトンファクトリの使用を強制します。
class XYZFactory {
static XYZFactory() {}
private XYZFactory(IBootstrapper bootstrapper) {
_bootstrapper = bootstrapper;
}
public static XYZFactory Instance {
get { return Singleton; }
}
public ABCType CreateABCType(string param1) {
return _bootstrapper.Resolve<ABCType>(param1, _bootstrapper.Resolve<Dependency1>);
}
private static readonly XYZFactory Singleton = XYZFactory(new DefaultBootstrapper);
private readonly IBootstrapper _bootstrapper;
}
問題は、ライブラリプロジェクトでコンポジションルートを見つけるために採用するより良いアプローチまたはより良いパターンがあるかどうかです。