12

IoCDIの違いを説明する多くのスレッドを読みましたが、多くの説明が互いに矛盾していましたが、それでも違いを理解するのに役立ったと思います。

そこで、ここで私の理解が正しいかどうかを尋ね、また、私を助けてくれた抜粋を投稿したいと思います (ただし、それらのいくつかは互いに矛盾しています)。

この件に関して多くのスレッドが行われたことは知っていますが、言及されたスレッドのOPのいずれも、関連するすべての投稿(さまざまなスレッドから)を示していたとは思わないため、このスレッドが閉じられないことを願っています彼らはついにそれを理解します。

とにかく、これが私がそれをどのように理解するかです(可能であれば、各質問に個別に対処/回答してください):

a)フレームワーク レベルでDIP原則を適用する場合、 IoCという用語を使用します。そして、フレームワーク レベルでDIPを実装するメカニズムの 1 つがDIですか?

b)下位レベル/非フレームワーク レベルでDIP ( DIを使用)を実装する場合、 IoCという用語は適用されません。その場合、単にDIと呼びますか?

c) DIは、依存関係の実際の作成と選択の制御を、関係する他の 2 つのいずれにも中立なサード パーティに渡すことで、DIPを達成するのに役立ちますか?

d) DIPがフレームワーク レベル(IoC) で ( DIを使用して)適用されると、3 種類の制御が反転します。

  1. インターフェイスの制御。現在、高レベル モジュールは、低レベル モジュールが準拠する必要があるインターフェイスを制御しており、その逆ではありません。

  2. 流れの制御。-->フレームワーク コード(ユーザー/ビジネス コードの代わりに) がプログラムのフローを制御します (つまり、フレームワーク (フレームワーク) があなた (ビジネス コード) と呼びます ) 。

  3. 依存関係の作成の制御。この逆転は、依存関係の実際の作成と選択の制御を、関与する他の2つのいずれにも中立なサードパーティに渡します。

e) DIPが非フレームワーク レベルで ( DIを使用して)適用されると、2 種類の制御が反転します。

  1. インターフェイスの制御。現在、高レベル モジュールは、低レベル モジュールが準拠する必要があるインターフェイスを制御しており、その逆ではありません。

  2. 依存関係の作成の制御。この逆転は、依存関係の実際の作成と選択の制御を、関与する他の2つのいずれにも中立なサードパーティに渡します。

?

以下は、役に立った抜粋です。

同じことを言うのに、なぜこれほど多くの用語が使われるのでしょうか? IoC と DIP

制御の反転は一般的な用語です。依存性注入は特定のタイプの IoC です

...

制御の反転は、フレームワーク/インフラストラクチャがアプリケーション コードを呼び出すときであり、その逆ではありません。

...

IoCを行わずにDIを行うことができます。「フレームワーク」や「インフラストラクチャ」がないため、ConsoleStringWriter を HelloWorld に挿入した場合、これを IoC とは考えません。

制御の反転 < 依存性注入

Fowler の定義を受け入れる場合、Inversion of Control は DI よりもはるかに広い用語であり、フレームワークにプラグインするすべてのフレームワークの使用法をカバーしますが、フレームワークは引き続き制御されます。依存関係の挿入は、依存関係を管理するために IoC を具体的に適用する IoC の特殊化です。

IoCとDIの違いはどこにありますか

IoC は、コントラクトの実装を変更する機能です。DI は、実装を提供する機能です。

...

従来のアプリケーションでは、開発者はビジネス コードとフレームワーク コードを記述していました。その後、ビジネス コードはフレームワーク コードを呼び出して、タスクを実行します。IoC モデルでは、そのモデルを「反転」し、ビジネス モジュールを受け入れてそれらを呼び出してタスクを実行するフレームワークを作成します。

依存性注入は、依存オブジェクトを外部呼び出し元によってクラス/メソッドに注入できるようにすることで、実装か​​ら内部依存性を削除する手法 (実際にはパターンと呼ぶのは難しい) です。IoC フレームワークは、依存性注入を使用して、ユーザー モジュールとその他の依存コードをフレームワーク ルーチンに提供し、「すべてを結合」します。依存性注入は IoC フレームワークで頻繁に使用されます。これは、それが "Call You" を可能にするメカニズムであるためです。

DIP 対 DI 対 IoC

DIP は、私たちを DI に導く原則です。基本的に、疎結合が目標であり、それを達成するには少なくとも 2 つの方法があります。• 依存性注入 • サービス ロケータ

依存性注入の良いアナロジーを持っている人はいますか?

制御の反転 (依存性注入はその実装です) の本質は、オブジェクトの使用とその管理を分離することです。

ioc と依存性注入の違い

依存性注入 (DI) と制御の反転 (IoC) という用語は、通常、同じ設計パターンを表すために同じ意味で使用されます (ただし、すべての人がその点に同意しているわけではなく、若干異なる方法で適用する傾向がある人もいます)。このパターンはもともと IoC と呼ばれていましたが、Martin Fowler は DI への移行を提案しました。これは、すべてのフレームワークが何らかの方法で制御を反転させ、制御のどの側面が反転されているかをより具体的にしたかったためです。

制御の反転と依存性注入

制御の反転 (IoC) とは、オブジェクトが作業を行うために依存する他のオブジェクトを作成しないことを意味します。代わりに、必要なオブジェクトを外部ソース (xml 構成ファイルなど) から取得します。依存関係の挿入 (DI) は、オブジェクトの介入なしで、通常はコンストラクター パラメーターを渡し、プロパティを設定するフレームワーク コンポーネントによって、これが行われることを意味します。

ありがとうございました

4

1 に答える 1

19

さて、これは私の見解です:

DIの概要

DIPは、抽象化に対してプログラミングすることを意味します。依存関係の種類を実装から抽象化に反転します。

IOCは、他の誰かが特定の抽象化の実装を取得する責任があることを意味します。通常、消費者はnewキーワードを使用して依存関係を取得します。IoC を使用すると、コンシューマーがインスタンスを作成する責任を負わないように、コントロールを反転できます。

依存関係の注入サービスの場所は、制御の反転の一部です。 DIvsSL

参照: https://stackoverflow.com/a/10053413/175399

于 2012-07-03T20:55:32.043 に答える