Dependency InjectionとService Locatorのパターンの違いは何ですか？

どちらのパターンも、制御の反転の原則の実装のように見えます。つまり、オブジェクトは依存関係の構築方法を知らないはずです。

Dependency Injection（DI）は、コンストラクターまたはセッターを使用して依存関係を「注入」するようです。

コンストラクターインジェクションの使用例：

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

Service Locatorは「コンテナ」を使用しているようです。これは依存関係を結び付け、fooにバーを提供します。

サービスロケーターの使用例：

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo()
  {
    this.bar = Container.Get<IBar>();
  }

  //...
}

私たちの依存関係は単なるオブジェクトそのものなので、これらの依存関係には依存関係があり、さらに多くの依存関係があり、以下同様です。このようにして、Inversion of Control Container（またはDI Container）が誕生しました。例：Castle Windsor、Ninject、Structure Map、Springなど）

ただし、IOC / DIコンテナはサービスロケータとまったく同じように見えます。それをDIコンテナーと呼ぶのは悪い名前ですか？IOC / DIコンテナは別のタイプのサービスロケータですか？多くの依存関係がある場合にDIコンテナーを使用するという事実のニュアンスはありますか？

違いはわずかに見えるかもしれませんが、ServiceLocatorを使用しても、クラスは依存関係の作成を担当します。それはサービスロケーターを使用して行うだけです。DIを使用すると、クラスに依存関係が与えられます。どこから来たのかわからないし、気にもしていない。これの重要な結果の1つは、DIの例の単体テストがはるかに簡単になることです。これは、依存するオブジェクトの実装のモックを渡すことができるためです。2つを組み合わせて、必要に応じてサービスロケータ（またはファクトリ）を挿入することもできます。

サービスロケーターを使用すると、すべてのクラスがサービスロケーターに依存します。これは、依存性注入には当てはまりません。依存関係インジェクターは通常、起動時に一度だけ呼び出され、依存関係をいくつかのメインクラスに挿入します。このメインクラスが依存するクラスは、完全なオブジェクトグラフが作成されるまで、依存関係が再帰的に挿入されます。

良い比較：http : //martinfowler.com/articles/injection.html

依存関係インジェクターがクラスがインジェクターを直接呼び出すサービスロケーターのように見える場合、それはおそらく依存関係インジェクターではなく、むしろサービスロケーターです。

サービスロケーターは依存関係を非表示にします。ロケーターから接続を取得するときに、オブジェクトがデータベースにヒットしたかどうか（たとえば）を見ても、オブジェクトを確認することはできません。依存関係の注入（少なくともコンストラクターの注入）では、依存関係は明示的です。

さらに、サービスロケータは他のオブジェクトの依存関係へのグローバルなアクセスポイントを提供するため、カプセル化を解除します。シングルトンと同様に、サービスロケータを使用します。

クライアントオブジェクトのインターフェイスの事前条件と事後条件を指定するのは難しくなります。これは、その実装の仕組みを外部から操作できるためです。

依存関係の注入では、オブジェクトの依存関係が指定されると、それらはオブジェクト自体の制御下に置かれます。

マーティンファウラーは次のように述べています。

サービスロケータを使用すると、アプリケーションクラスはロケータへのメッセージによって明示的に要求します。インジェクションの場合、明示的な要求はなく、サービスはアプリケーションクラスに表示されます。つまり、制御が反転します。

つまり、Service LocatorとDependency Injectionは、Dependency Inversion Principleの単なる実装です。

重要な原則は、「具体化ではなく抽象化に依存すること」です。これにより、ソフトウェア設計が「疎結合」、「拡張可能」、「柔軟」になります。

ニーズに最適なものを使用できます。巨大なコードベースを持つ大きなアプリケーションの場合、依存関係注入はコードベースにさらに変更を加える必要があるため、サービスロケーターを使用することをお勧めします。

あなたはこの投稿をチェックすることができます：依存関係の逆転：Service LocatorまたはDependency Injection

また、クラシック：制御コンテナの反転とMartin FowlerによるDependency Injectionパターン

Ralph E. Johnson＆Brian Footeによる再利用可能なクラスの設計

しかし、私の目を開いたのは、ASP.NET MVC：解決または注入ですか？それが問題です…Dino Espositoによる

コンストラクターDIを使用するクラスは、満たすべき依存関係があることをコードを使用するように指示します。クラスがSLを内部で使用してそのような依存関係を取得する場合、使用するコードは依存関係を認識しません。これは表面上は良いように見えるかもしれませんが、明示的な依存関係を知ることは実際に役立ちます。建築の観点からはより良いです。また、テストを行うときは、クラスに特定の依存関係が必要かどうかを把握し、それらの依存関係の適切な偽バージョンを提供するようにSLを構成する必要があります。DIでは、偽物を渡すだけです。大きな違いはありませんが、それはあります。

ただし、DIとSLは一緒に機能します。一般的な依存関係（設定、ロガーなど）を一元的に配置すると便利です。このようなdepを使用するクラスを指定すると、depを受け取る「実際の」コンストラクターと、SLから取得して「実際の」コンストラクターに転送するデフォルト（パラメーターなし）コンストラクターを作成できます。

編集：そしてもちろん、SLを使用する場合、そのコンポーネントへの結合を導入します。皮肉なのは、そのような機能の概念が抽象化を促進し、結合を減らすことであるからです。懸念はバランスを取ることができ、SLを使用する必要がある場所の数によって異なります。上記のように行われた場合は、デフォルトのクラスコンストラクターでのみ。

どちらもIoCの実装手法です。制御の反転を実装する他のパターンもあります。

• 工場パターン
• サービスロケーター
• DI（IoC）コンテナー
• 依存性注入（コンストラクター注入、パラメーター注入（必要でない場合）、インターフェース注入のセッター注入）...

サービスロケーターとDIコンテナーはより類似しているように見えます。どちらもコンテナーを使用して依存関係を定義し、抽象化を具体的な実装にマッピングします。

主な違いは、依存関係がどのように配置されているか、サービスロケーターではクライアントコードが依存関係を要求すること、DIコンテナーではすべてのオブジェクトを作成するためにコンテナーを使用し、コンストラクターパラメーター（またはプロパティ）として依存関係を注入することです。

私の最後のプロジェクトでは、両方を使用しています。単体テストのために依存性注入を使用します。サービスロケーターを使用して、実装を非表示にし、IoCコンテナーに依存しています。はい！IoCコンテナー（Unity、Ninject、Windsor Castle）のいずれかを使用すると、それに依存します。そして、それが古くなった場合、または何らかの理由でスワップしたい場合は、実装を変更する必要があります（少なくとも構成ルート）。しかし、サービスロケータはそのフェーズを抽象化します。

IoCコンテナに依存しない方法は？自分でラップする必要があるか（これは悪い考えです）、またはService Locatorを使用してIoCコンテナーを構成します。そのため、必要なインターフェースを取得するようにサービスロケーターに指示し、そのインターフェースを取得するように構成されたIoCコンテナーを呼び出します。

私の場合、フレームワークコンポーネントであるServiceLocatorを使用します。そして、Unity for IoCコンテナーを使用します。今後、IoCコンテナをNinjectに交換する必要がある場合 UnityではなくNinjectを使用するようにサービスロケーターを構成する必要があります。簡単な移行。

以下は、このシナリオを説明する素晴らしい記事です。 http://www.johandekoning.nl/index.php/2013/03/03/dont-wrap-your-ioc-container/

この2つは連携していると思います。

依存性注入とは、依存クラス/インターフェースを消費クラス（通常はコンストラクター）にプッシュすることを意味します。これは、インターフェースを介して2つのクラスを分離し、消費クラスが多くのタイプの「注入された依存関係」実装で機能できることを意味します。

サービスロケーターの役割は、実装をまとめることです。プログラムの開始時に、いくつかのブートストラップを使用してサービスロケータをセットアップします。ブートストラップは、実装のタイプを特定の抽象/インターフェースに関連付けるプロセスです。実行時に作成されます。（設定またはブートストラップに基づく）。依存性注入を実装していない場合、サービスロケータまたはIOCコンテナを利用することは非常に困難です。

追加する理由の1つは、先週MEFプロジェクト用に書いたドキュメントの更新に触発されました（MEFの構築を手伝います）。

アプリが数千のコンポーネントで構成される可能性がある場合、特定のコンポーネントを正しくインスタンス化できるかどうかを判断するのは困難です。「正しくインスタンス化された」とは、Fooコンポーネントに基づくこの例では、のインスタンスIBarが利用可能であり、それを提供するコンポーネントが次のことを実行することを意味します。

• 必要な依存関係がある
• 無効な依存サイクルに関与していない、および
• MEFの場合、1つのインスタンスのみで提供されます。

コンストラクタはその依存関係を取得するためにIoCコンテナに行くあなたが与えた第二の例では、あなたがのインスタンスがあることをテストする唯一の方法Fooを正しくインスタンス化することができるようになりますあなたのアプリケーションの実際の実行時設定では、することです実際に構築しますそれ。

実行時に機能するコードは必ずしもテストハーネスで機能するとは限らないため、これにはテスト時にあらゆる種類の厄介な副作用があります。実際の構成はテストする必要があるものであり、テスト時のセットアップではないため、モックは機能しません。

この問題の原因は、@ Jonによってすでに呼び出されている違いです。2番目のバージョンでは命令型のサービスロケーターパターンが使用されていますが、コンストラクターを介した依存関係の注入は宣言型です。

IoCコンテナーを注意深く使用すると、関係するコンポーネントのインスタンスを実際に作成することなく、アプリのランタイム構成を静的に分析できます。多くの一般的なコンテナは、これのいくつかのバリエーションを提供します。Microsoft.Composition.NET 4.5 WebおよびMetroスタイルアプリを対象とするMEFのバージョンであるCompositionAssertは、wikiドキュメントでサンプルを提供しています。それを使用して、次のようなコードを書くことができます：

 // Whatever you use at runtime to configure the container
var container = CreateContainer();

CompositionAssert.CanExportSingle<Foo>(container);

（見る この例を）。

を検証することによって テスト時にアプリケーションの構成ルートを、プロセスの後の段階でテストをすり抜ける可能性のあるエラーを見つけることができます。

これがトピックに関するこの他の包括的な回答セットへの興味深い追加であることを願っています！

注：質問に正確に答えているわけではありません。しかし、これは、Service Locator（アンチ）パターンと混同されているDependency Injectionパターンの新しい学習者に役立つと思いますこのページに偶然出くわすます。

Service Locator（現在はアンチパターンと見なされているようです）とDependency Injectionパターンの違いを知っており、各パターンの具体例を理解できますが、コンストラクター内のサービスロケーターの例に混乱しました（コンストラクター注入を再実行します）。

"Service Locator"は、パターンの名前と、そのパターンで使用されるオブジェクトを参照するための名前（両方とも想定）の両方として使用され、new演算子を使用せずにオブジェクトを取得します。これで、同じタイプのオブジェクトをコンポジションルートでも使用できます依存性注入を実行する、混乱が生じます。

重要なのは、DIコンストラクタ内でサービスロケータオブジェクトを使用している可能性があるが、「サービスロケータパターン」を使用していないことです。本質的に同じことをしていると思っているかもしれませんが、IoCコンテナーオブジェクトとして参照する方が混乱しにくいです（間違っている場合は修正してください）。

サービスロケーター（または単にロケーター）と呼ばれる場合でも、IoCコンテナー（または単にコンテナー）と呼ばれる場合でも、同じ抽象化を参照している可能性があるため、違いはありません（私が間違っている場合は修正してください） ）。それをサービスロケーターと呼ぶのは、依存関係注入パターンと一緒にサービスロケーターアンチパターンを使用していることを示唆しているだけです。

私見、それを「場所」や「場所」ではなく「ロケーター」と名付けると、記事のサービスロケーターがサービスロケーターコンテナーを参照しているのではなく、サービスロケーター（アンチ）パターンを参照していると考えることもあります。特に、Dependency Injectorではなく、Dependency Injectionと呼ばれる関連パターンがある場合。

この単純化しすぎた場合、違いはなく、同じように使用できます。ただし、現実の問題はそれほど単純ではありません。Barクラス自体にDという名前の別の依存関係があると仮定してください。その場合、サービスロケータはその依存関係を解決できず、Dクラス内でインスタンス化する必要があります。依存関係をインスタンス化するのはクラスの責任だからです。Dクラス自体に他の依存関係があり、実際の状況では通常、それよりもさらに複雑になると、さらに悪化します。このようなシナリオでは、DIはServiceLocatorよりも優れたソリューションです。

Dependency InjectionとService Locatorの違い（ある場合）は何ですか？どちらのパターンも、依存関係の逆転の原則の実装に適しています。Service Locatorパターンは、パブリックインターフェイスに変更を強制せずに全体的な設計を緩和するため、既存のコードベースでの使用が容易です。これと同じ理由で、Service Locatorパターンに基づくコードは、依存性注入に基づく同等のコードよりも読みにくくなります。

Dependency Injectionパターンは、クラス（またはメソッド）がどの依存関係を持つかというシグネチャを明確にします。このため、結果のコードはより簡潔で読みやすくなっています。

単純な概念に従うことで、Service LocatorとDIコンテナーの違いをより明確に理解できました。

• Service Locatorはコンシューマーで使用され、直接のコンシューマーの要求により、ストレージからIDでサービスを取得します

• DIコンテナーは外部のどこかにあり、ストレージからサービスを取得してコンシューマーにプッシュします（コンストラクターまたはメソッドを介して）

ただし、これらの違いについては、具体的な消費者の使用状況でのみ説明できます。Service LocatorとDIコンテナーをコンポジションルートで使用する場合、それらはほとんど同じです。

DIコンテナーは、サービスロケーターのスーパーセットです。これは、依存関係の注入を組み立てる（配線する）追加機能とともに、サービスを見つけるために使用できます。

記録のために

//Foo Needs an IBar
public class Foo
{
  private IBar bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

本当にインターフェースが必要でない限り（インターフェースは複数のクラスで使用されます）、それを使用してはいけません。この場合、IBarでは、それを実装するサービスクラスを利用できます。ただし、通常、このインターフェイスは単一のクラスによって使用されます。

インターフェースを使用するのが悪いのはなぜですか？デバッグが本当に難しいからです。

たとえば、インスタンス「バー」が失敗したとしましょう、質問：どのクラスが失敗しましたか？。 どのコードを修正する必要がありますか？ 単純なビュー、それはインターフェースにつながり、私の道はここで終わります。

代わりに、コードがハード依存関係を使用している場合、間違いをデバッグするのは簡単です。

//Foo Needs an IBar
public class Foo
{
  private BarService bar;

  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  //...
}

「bar」が失敗した場合は、BarServiceクラスを確認して実行する必要があります。