.NETにDIを実装する「正しい」方法は何ですか？

比較的大きなアプリケーションに依存性注入を実装したいと考えていますが、経験はありません。私は、UnityやNinjectなどのIoCの概念といくつかの実装、および利用可能な依存関係インジェクターを研究しました。しかし、私を避けているものが1つあります。アプリケーションでインスタンス作成を整理するにはどうすればよいですか？

私が考えているのは、いくつかの特定のクラスタイプのオブジェクトを作成するロジックを含むいくつかの特定のファクトリを作成できるということです。基本的に、このクラスの静的カーネルインスタンスのNinject Get（）メソッドを呼び出すメソッドを持つ静的クラス。

アプリケーションに依存性注入を実装する正しいアプローチでしょうか、それとも他の原則に従って実装する必要がありますか？

使用するツールについてはまだ考えないでください。IoCコンテナなしでDIを実行できます。

最初のポイント：Mark Seemannには、.NetのDIに関する非常に良い本があります

2番目：コンポジションルート。プロジェクト全体のエントリポイントで設定が完了していることを確認してください。残りのコードは、使用されているツールについてではなく、注入について知っている必要があります。

3番目：コンストラクターインジェクションは、最も可能性の高い方法です（必要ない場合もありますが、それほど多くはありません）。

4番目：ラムダファクトリと他の同様の機能を使用して、インジェクションのみの目的で不要なインターフェイス/クラスを作成しないようにします。

質問には2つの部分があります。DIを適切に実装する方法と、DIを使用するために大規模なアプリケーションをリファクタリングする方法です。

最初の部分は@Miyamoto Akiraによってよく回答されています（特に、Mark Seemannの「.netでの依存性注入」の本を読むことをお勧めします。Marks ブログも無料の良いリソースです。

2番目の部分はかなり複雑です。

良い最初のステップは、すべてのインスタンス化を単純にクラスコンストラクターに移動することですnew。依存関係を注入せず、コンストラクターでのみ呼び出すようにしてください。

これにより、これまでに行ったすべてのSRP違反が強調表示されるため、クラスをより小さな協力者に分類し始めることができます。

次の問題は、構築時に実行時パラメーターに依存するクラスです。通常、これを修正するには、単純なファクトリを作成Func<param,type>します。多くの場合、でコンストラクタを初期化し、メソッドで呼び出します。

次の手順では、依存関係のインターフェイスを作成し、これらのインターフェイスを除くクラスに2つ目のコンストラクタを追加します。パラメーターなしのコンストラクターは、具象インスタンスを更新し、それらを新しいコンストラクターに渡します。これは一般に「B * stard Injection」または「Poor mans DI」と呼ばれます。

これにより、ユニットテストを実行できるようになります。それがリファクタリングの主な目標である場合は、停止することができます。新しいコードはコンストラクターインジェクションで記述されますが、古いコードは記述されたまま動作し続けますが、それでもテスト可能です。

もちろん、さらに先へ進むことができます。IOCコンテナーを使用する場合、次のステップはnew、パラメーターレスコンストラクターへのすべての直接呼び出しをIOCコンテナーへの静的呼び出しに置き換え、基本的に（ab）サービスロケーターとして使用することです。

これにより、以前と同様に処理するランタイムコンストラクターパラメーターのケースが多くなります。

これが完了すると、パラメータのないコンストラクターの削除を開始し、純粋なDIにリファクタリングできます。

最終的にこれは多くの作業になるので、なぜそれをしたいのかを決定し、リファクタリングから最も恩恵を受けるコードベースの部分に優先順位を付けてください

最初に、新しいプロジェクトを開始するのではなく、既存のプロジェクトをリファクタリングすることにより、これを自分自身で非常に難しくしていることに言及したいと思います。

あなたはそれが大きなアプリケーションだと言ったので、最初から小さなコンポーネントを選んでください。できれば、「リーフノード」コンポーネントで、他のコンポーネントによって使用されていないものを使用してください。このアプリケーションの自動テストの状態はわかりませんが、このコンポーネントのすべての単体テストに違反することになります。そのために準備してください。ステップ0は、まだ存在しない場合に変更するコンポーネントの統合テストを作成しています。最後の手段として（テストインフラストラクチャなし、それを記述するための賛同なし）、このコンポーネントが機能していることを確認するために実行できる一連の手動テストを見つけてください。

DIリファクタリングの目標を述べる最も簡単な方法は、このコンポーネントから「new」演算子のすべてのインスタンスを削除することです。これらは一般に2つのカテゴリに分類されます。

1. 不変メンバー変数：これらは一度（通常はコンストラクターで）設定される変数であり、オブジェクトの存続期間中は再割り当てされません。これらの場合、オブジェクトのインスタンスをコンストラクターに注入できます。通常、これらのオブジェクトを破棄する責任はありません（ここでは絶対に言いたくありませんが、実際にその責任を負うべきではありません）。

2. バリアントメンバー変数/メソッド変数：これらは、オブジェクトの存続期間中のある時点でガベージコレクションが行われる変数です。これらのために、これらのインスタンスを提供するためにクラスにファクトリーを注入する必要があります。ファクトリーによって作成されたオブジェクトを破棄する責任があります。

IoCコンテナー（その名のとおり）は、これらのオブジェクトをインスタンス化し、ファクトリーインターフェースを実装する責任を負います。変更したコンポーネントを使用しているものは何でも、コンポーネントを取得できるようにIoCコンテナについて知る必要があります。

上記を完了すると、選択したコンポーネントのDIから得たいと思っているメリットを享受できます。これらの単体テストを追加/修正する良い機会になります。既存の単体テストがあった場合、実際のオブジェクトを注入してパッチを適用するか、モックを使用して新しい単体テストを作成するかを決定する必要があります。

アプリケーションの各コンポーネントに対して上記を「単純に」繰り返し、メインのみがそれを知る必要があるまで、IoCコンテナーへの参照を上に移動します。

正しいアプローチは、使用する場合、コンストラクター注入を使用することです

私が考えているのは、いくつかの特定のクラスタイプのオブジェクトを作成するロジックを含むいくつかの特定のファクトリを作成できるということです。基本的に、このクラスの静的カーネルインスタンスのNinject Get（）メソッドを呼び出すメソッドを持つ静的クラス。

依存性注入よりも、サービスロケーターになります。

あなたはそれを使いたいと言いますが、その理由は述べません。

DIは、インターフェイスから結石を生成するメカニズムを提供する以外の何物でもありません。

これ自体はDIPに由来します。コードが既にこのスタイルで記述されており、結石が生成される場所が1つしかない場合、DIはそれ以上何もパーティーにもたらしません。ここにDIフレームワークコードを追加すると、コードベースが単純に大きくなり難読化されます。

使用したいと仮定すると、通常、アプリケーション/アプリケーションの初期段階でファクトリー/ビルダー/コンテナー（またはその他）をセットアップして、明確に見えるようにします。

注意：Ninject / StructureMapなどにコミットするのではなく、希望する場合は簡単にロールバックできます。しかし、スタッフの適度な離職がある場合は、認知されたフレームワークを使用するために車輪に油を塗るか、少なくともそのスタイルでそれを書いて、学習曲線になりすぎないようにすることができます。

実際、「正しい」方法は、他の選択肢がまったくない場合を除き、工場をまったく使用しないことです（単体テストや特定のモックのように-量産コードの場合は工場を使用しません）。そうすることは、実際にはアンチパターンであり、どんな場合でも避けるべきです。DIコンテナーの背後にある全体的なポイントは、ガジェットが作業を行えるようにすることです。

前の投稿で前述したように、IoCガジェットにアプリ内のさまざまな依存オブジェクトの作成を担当させる必要があります。つまり、DIガジェットにさまざまなインスタンス自体を作成および管理させます。これがDIの背後にある全体のポイントです。オブジェクトは、依存するオブジェクトを作成および/または管理する方法を決して知ってはいけません。そうしないと、疎結合が壊れます。

既存のアプリケーションをすべてのDIに変換することは大きなステップですが、そうする際の明らかな困難は別として、あなたのバインディングの大部分を自動的に実行するDIツールを探索することも必要になります。 （Ninjectのようなものの中核は、"kernel.Bind<someInterface>().To<someConcreteClass>()"インターフェイス宣言をそれらのインターフェイスを実装するために使用したい具体的なクラスに一致させるために行う呼び出しです。DI ガジェットがコンストラクター呼び出しをインターセプトして提供できるようにする「バインド」呼び出しですいくつかのクラスの典型的なコンストラクター（ここに示す擬似コード）は次のとおりです。

public class SomeClass
{
  private ISomeClassA _ClassA;
  private ISomeOtherClassB _ClassB;

  public SomeClass(ISomeClassA aInstanceOfA, ISomeOtherClassB aInstanceOfB)
  {
    if (aInstanceOfA == null)
      throw new NullArgumentException();
    if (aInstanceOfB == null)
      throw new NullArgumentException();
    _ClassA = aInstanceOfA;
    _ClassB = aInstanceOfB;
  }

  public void DoSomething()
  {
    _ClassA.PerformSomeAction();
    _ClassB.PerformSomeOtherActionUsingTheInstanceOfClassA(_ClassA);
  }
}

そのコードのどこにも、SomeConcreteClassAまたはSomeOtherConcreteClassBのインスタンスを作成/管理/リリースするコードがなかったことに注意してください。実際のところ、どちらの具体的なクラスも参照されていません。それで...魔法はどこで起こったのですか？

アプリの起動部分では、次の処理が行われました（これも擬似コードですが、実際の（Ninject）にかなり近い...）：

public void StartUp()
{
  kernel.Bind<ISomeClassA>().To<SomeConcreteClassA>();
  kernel.Bind<ISomeOtherClassB>().To<SomeOtherConcreteClassB>();
}

そこにある少しのコードは、Ninjectガジェットにコンストラクターを探し、それらをスキャンし、処理するように構成されたインターフェースのインスタンスを探して（「バインド」呼び出し）、どこでも具象クラスのインスタンスを作成して置換するように指示しますインスタンスが参照されます。

Ninjectを補完する優れたツールがあり、Ninject.Extensions.Conventions（別のNuGetパッケージ）と呼ばれ、この作業の大部分を実行します。これを自分で構築する際に経験する優れた学習体験から離れることはありませんが、自分で始めるには、これは調査するためのツールかもしれません。

メモリが機能する場合、Unity（以前はMicrosoftから現在はオープンソースプロジェクト）には、同じことを行うメソッド呼び出しが2つあり、他のツールには同様のヘルパーがあります。

DIトレー​​ニングの大部分については、Mark Seemannの本を読んでくださいNinjectの本で、Ninject専用に書かれた別のリソースを紹介します。私はそれと良い読み物を持っています：Dependency InjectionのためのNinjectの習得

「正しい方法」はありませんが、従うべき簡単な原則がいくつかあります。

• アプリケーションの起動時にコンポジションルートを作成する
• コンポジションルートが作成された後、DIコンテナ/カーネルへの参照を破棄します（または、少なくともそれをカプセル化して、アプリケーションから直接アクセスできないようにします）
• 「新規」経由でインスタンスを作成しないでください
• 必要なすべての依存関係を抽象化としてコンストラクターに渡します

それで全部です。確かに、それは法律ではなく原則ですが、あなたがそれらに従うなら、あなたはDIをすることを確信できます（私が間違っているなら私を修正してください）。

では、「新規」なしでDIコンテナを知らずに、実行時にオブジェクトを作成する方法は？

NInjectの場合、ファクトリーの作成を提供するファクトリー拡張があります。もちろん、作成されたファクトリーにはカーネルへの内部参照がまだありますが、アプリケーションからはアクセスできません。