IoCとDIの違いはどこですか
可能性のある複製：
制御の反転<依存性注入
私は常に同じコンテキストでIoC（制御の反転）とDI（依存性注入）を読みます。 IoCとDIの違いは何ですか？ IoCとDIの違いは何ですか？
一般的な用法では、用語はやや同義語になっています。 IoCの元のアイデア-制御の反転-は、「ハリウッドの原則」に非常に関連していました：私たちに電話しないでください、私たちはあなたに電話します。
従来のアプリケーションでは、開発者はビジネスコードとフレームワークコードを記述していました。次に、ビジネスコードはフレームワークコードを呼び出してタスクを実行します。 IoCモデルでは、そのモデルを「反転」して、ビジネスモジュールを受け入れ、それらを呼び出してタスクを実行するフレームワークを作成します。この原則は、古いSmart Client Software Factoryおよび新しいPrism（またはWPF/Silverlightの複合アプリケーション）を含むいくつかの開発フレームワークで示されています。これらのモデルでは、UIモジュールはIoCコンテナーに登録され、構成とユーザーアクションに基づいて必要に応じて読み込まれます。これらのモデルは強力ですが、学習曲線が非常に急になる傾向があります。
依存関係の注入は、外部の呼び出し元が依存オブジェクトをクラス/メソッドに注入できるようにすることで、実装から内部の依存関係を削除する（実際にはパターンとは言いがたい）手法です。 IoCフレームワークは、依存性注入を使用して、ユーザーモジュールと他の依存コードをフレームワークルーチンに提供します。依存性注入は、IoCフレームワークが「呼び出し」を可能にするメカニズムであるため、IoCフレームワークで頻繁に使用されます。
Castle WindsorやStructure MapなどのIoCコンテナーは、登録されたクラスの自動インスタンス化とライフサイクル管理（登録されたクラスに必要なパラメーターの自動インスタンス化と注入を含む）を提供することにより、依存性注入を支援します。これにより、依存性注入が使いやすくなりますが、必須ではありません。
依存性注入は、特定の実装への依存性を最小限にしながら、インターフェイスへの依存性を最大化する柔軟性のためのメカニズムです。その結果、依存性注入を使用するシステムは、状況に応じて使用できる「プラグ可能な」実装クラスをサポートできます。この「プラグイン可能性」の非常に大きな利点は、単体テストの作成がはるかに簡単になることです。オブジェクトを必要なインターフェイスにモックしてから、テストオブジェクトに挿入できます。
つまり、IoCは実際にはより広範な原則であり、DIはその中の基本的な手法です。 IoC（ハリウッドの原理）システムはかなり複雑になる傾向があり、理解が難しいため、学習曲線が急になります。一方、DIは日常の開発者にとっては良い習慣です。私は、クールで複雑なものよりも、わかりやすく明確である傾向があります。
IoCは、契約の実装を変更する機能です。
DIは、実装を提供する機能です。