8

私はここで議論に関する他のさまざまな質問を読みました、特に特に

依存性注入(DI)「フレンドリー」ライブラリ

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;
}

問題は、ライブラリプロジェクトでコンポジションルートを見つけるために採用するより良いアプローチまたはより良いパターンがあるかどうかです。

4

1 に答える 1