web-dev-qa-db-ja.com

依存関係注入で構成をどのように管理しますか？

私はDI/IOCの大ファンです。ハードな依存関係を処理/抽出するのに最適であり、生活が少し楽になります。

しかし、私はそれに少し不満があり、それを解決する方法がわかりません。

DI/IOCの基本的な考え方は、オブジェクトがインスタンス化されると、そのすべての依存関係がコンストラクター内に事前に入力されるということです。

ただし、私見では、コンストラクターのパラメーターにはいくつかの種類があります（特にオブジェクトが不変の場合）。

  1. 依存関係（オブジェクトが機能するために必要なオブジェクト）
  2. 構成（作業に必要な環境に関する情報）
  3. パラメータ（作業が行われるデータ）

私はIOCが依存関係でうまく機能することを発見しました。しかし、私はまだ他の2つを処理するための最良の方法を考え出そうとしています。しかし、コンストラクターは= IOCコンテナ、これらのアイテムをIOCコンテナに配置する必要があるようです。

人々が採用している戦略/パターンと、人々が見つけた利点と欠点を知りたいのですが。

NB。私はこれが非常に主観的な質問であることを認識しており、SEガイドラインに従ってそれを「良い」主観的な質問にしようとしました。

design-patternsconfiguration-managementinversion-of-control
18
ArTs

構成（作業に必要な環境に関する情報）

環境に関する情報を提供することを目的とする構成クラス（うるさい：インターフェース+実装）を作成します。これにより、構成が、オブジェクトが機能するために必要な他のオブジェクトとまったく同じになります（ポイント1）。

パラメータ（作業が行われるデータ）

オブジェクト指向環境では、プリミティブデータ型をオブジェクトにカプセル化できるため、これもポイント1につながります。しかし、おそらく this SO question 興味深いことに気づくでしょう。 DIコンテナーを使用する場合、コンストラクターのプリミティブパラメーターの状況を正確に処理します。この例では、設計を改善できるため、コンストラクターでプリミティブ型を完全に使用する必要がなくなりました。

9
Doc Brown

私が行うことは、これらのケースのファクトリパターンです。

オブジェクト自体を依存関係として使用しませんが、コンテナーによって自動的にバインドできないパラメーターを受け入れるGetメソッドを使用してファクトリオブジェクトを作成します。

例：

 interface IDependencyObject {
       ....
 }

 class DependencyObject {

      public DependencyObject(int primitive, IAnotherDependency anotherDependency) {
      ...
      }

 }

 class DependencyObjectFactory {

      private readonly IAnotherDependency anotherDependency;

      public DependencyObjectFactory(IAnotherDependency anotherDependency) {
           this.anotherDependency = anotherDependency;
      }

      public IDependencyObject Get(int primitive) {
           return new DependencyObject(primitive, anotherDependency);
      }
 }

 interface IDependencyObjectFactory {
       IDependencyObject Get(int primitive);
 }
1
Vilém Procházka