7

3 つのイディオムの違いについては、多くの投稿をお読みください。しかし、さらに混乱して、次の記事に出くわしました: http://martinfowler.com/articles/injection.html

これが正しいかどうかを確認したいだけです。私が間違っている場合は修正してください。訂正・追加をお知らせください：

IoC は、アプリケーションが使用するサービスの実装からアプリケーションを切り離すという概念です。アプリケーションには Iservice への参照が含まれており、具体的なサービスのインスタンス化は担当していません。

これを実現するには、少なくとも 2 つの方法があります。

  1. DI - 具体的なサービスは、ctor パラメータとして注入される/setter をスローする/インターフェース注入をスローする (後者はどういう意味ですか? )

  2. ServiceLocator - アプリケーションが必要とする可能性のあるすべての具体的なサービスを認識するコンポーネントです。アプリケーションは、Locator から具体的なサービスを明示的に要求します。

*IoC コンテナーは、実際にはコントロールのファクトリー (「プロバイダー」) です。

この記事の「いつ (1) または (2) を選択するか」という部分に少し混乱しました。誰かが自分の経験から素人の言葉で教えてもらえますか?

「Service Locator は、より単純な動作のため、わずかに優れています。ただし、複数のアプリケーションで使用するクラスを構築する場合は、依存性注入を選択することをお勧めします。」--> locator はどのようにより単純なのか? メソッド呼び出しを明示的に使用するためですか？複数のアプリケーションがある場合、DI を使用すると何が良いでしょうか?

4

1 に答える 1

4

IoC は、アプリケーションが使用するサービスの実装からアプリケーションを切り離すという概念です。

確かに、IoC はインターフェイスを実装から分離することと密接に関連していますが、私はそれをより一般的な原則と考えています。This SO answerは、概念の非常に良い説明を提供します。

これを実現するには、少なくとも 2 つの方法があります:
1) DI
2) ServiceLocator

Service Locator パターンが Inversion of Control の例であるとは言いません。まったく逆です。Service Locator を使用している場合は、必要な依存関係をアクティブな方法で取得しているため、他の誰もそれを実行しません (コンテナが依存関係を処理する DI とは対照的に、そうする可能性 - セッター、コンストラクターパラメーター、または注入インターフェースのメソッドを実装することによって)。

ロケーターはどのようにより簡単ですか? メソッド呼び出しを明示的に使用しているためですか？

Martin Fowler は IoC の一般的な考え方に言及していると思います。これは、IoC/DI の概念が以前に使用されたことがない場合、コードを理解しにくくする可能性があるためです。一方、Service Locator を使用していくつかの依存関係を取得するコードは、最初の遭遇で把握しやすい場合があります。

複数のアプリケーションがある場合、DI を使用すると何が良いでしょうか?

再利用可能なコンポーネントを作成する場合、DI の利点は、コンポーネントが元の依存関係以外に依存しないことです (MF の例では、DI を使用する場合、MovieLister は MovieFinder インターフェイスのみに依存します)。 ）。また、他の人があなたのコンポーネントを使用するのは非常に簡単です。あなたが提供した DI の手段を使用して依存関係を渡すだけです。

Service Locator を使用する場合は、Service Locator 自体のインターフェースにも依存関係を追加します。Locator 用の分離されたインターフェイスを使用すると、問題にならない場合があります。しかし、MF が書いているように、コンポーネントのユーザーがコンポーネントの依存関係を満たすことも難しくなる可能性があります。

リスタが、他の人が書いているアプリケーションに私が提供しているコンポーネントである場合、違いが生じます。この場合、顧客が使用する予定のサービス ロケータの API についてはあまり知りません。各顧客は、互換性のない独自のサービス ロケーターを持っている可能性があります。

于 2011-09-10T22:16:11.563 に答える