IOC表示外部类管理应用程序的类，而外部类表示容器管理应用程序类之间的依赖关系。 IOC的基本概念是程序员不需要创建对象，而是描述如何创建对象。

IoC容器执行的主要任务是: 实例化应用程序类。配置对象。组装对象之间的依赖关系。

DI是通过使用setter注入或构造函数注入在运行时提供对象依赖关系的过程。

控制反转是一种设计范式，其目标是为应用程序的目标组件提供更多的控制，即完成工作的组件。 依赖注入是一种模式，用于创建其他对象所依赖的对象实例，而在编译时不知道将使用哪个类来提供该功能。

实现控制反转有几种基本技术。这些都是:

使用工厂模式 使用服务定位器模式 使用任何给定类型的依赖注入: 1).构造函数注入 2). setter注入 3).接口注入

关于这个问题，我想说维基已经提供了详细易懂的解释。我引用这里最重要的。

国际奥委会的实施

在面向对象编程中，有几种基本的技术来实现 实现控制反转。这些都是: 使用依赖注入，用于 构造函数注入参数注入Setter注入 接口注入; 使用上下文化查找; 采用模板法设计模式; 使用策略设计模式

至于依赖注入

依赖注入是一种技术，一个对象(或静态的 方法)提供了另一个对象的依赖关系。依赖关系是 可以使用的对象(服务)。注入是传递 对使用它的依赖对象(客户端)的依赖。

与其直接对比DI和IoC，不如从头开始:每个重要的应用程序都依赖于其他代码段。

所以我写一个类，MyClass，我需要调用一个方法YourService…我需要以某种方式获取YourService的一个实例。最简单、最直接的方法是自己实例化它。

YourService service = new YourServiceImpl();

直接实例化是获取依赖项的传统(过程性)方法。但它有许多缺点，包括MyClass与YourServiceImpl的紧密耦合，这使得我的代码难以更改和测试。MyClass并不关心YourService的实现是什么样子，所以MyClass不想负责实例化它。

我更喜欢把这个责任从MyClass转移到MyClass之外的东西。最简单的方法是将实例化调用(new YourServiceImpl();)移动到其他类中。我可以将这个类命名为Locator，或者Factory，或者其他任何名称;但重点是MyClass不再对YourServiceImpl负责。我颠倒了依赖关系。太好了。

问题是，MyClass仍然负责对定位器/工厂/任何东西的调用。因为我反转依赖关系所做的全部工作就是插入一个中间人，所以现在我耦合到中间人(即使我没有耦合到中间人给我的具体对象)。

我并不真正关心依赖项来自何处，因此我宁愿不负责进行检索依赖项的调用。仅仅反转依赖本身是不够的。我想反转整个过程的控制。

What I need is a totally separate piece of code that MyClass plugs into (call it a framework). Then the only responsibility I'm left with is to declare my dependency on YourService. The framework can take care of figuring out where and when and how to get an instance, and just give MyClass what it needs. And the best part is that MyClass doesn't need to know about the framework. The framework can be in control of this dependency wiring process. Now I've inverted control (on top of inverting dependencies).

将MyClass连接到框架中有不同的方法。注入就是这样一种机制，通过这种机制，我只需声明一个我期望框架提供的字段或参数，通常是在它实例化MyClass时。

我认为所有这些概念之间的关系层次比这个线程中的其他图表所显示的要稍微复杂一些;但其基本思想是，这是一种等级关系。我觉得这和野外的DIP是同步的。

IOC(控制反转):将获取对象实例的控制权交给容器称为控制反转，这意味着不是您使用new操作符创建对象，而是让容器为您创建对象。

DI(依赖注入):向对象注入属性的方式称为依赖注入。

我们有三种类型的依赖注入:

构造函数注入 Setter和Getter注入 接口注入

Spring只支持构造函数注入和Setter/Getter注入。

让我们从SOLID的D开始，看看Scott Millett的书《Professional ASP. IoC》中的DI和IoC。NET设计模式":

Dependency Inversion Principle (DIP) The DIP is all about isolating your classes from concrete implementations and having them depend on abstract classes or interfaces. It promotes the mantra of coding to an interface rather than an implementation, which increases flexibility within a system by ensuring you are not tightly coupled to one implementation. Dependency Injection (DI) and Inversion of Control (IoC) Closely linked to the DIP are the DI principle and the IoC principle. DI is the act of supplying a low level or dependent class via a constructor, method, or property. Used in conjunction with DI, these dependent classes can be inverted to interfaces or abstract classes that will lead to loosely coupled systems that are highly testable and easy to change. In IoC, a system’s flow of control is inverted compared to procedural programming. An example of this is an IoC container, whose purpose is to inject services into client code without having the client code specifying the concrete implementation. The control in this instance that is being inverted is the act of the client obtaining the service.

米勒特,C(2010)。专业的ASP。NET设计模式。威利出版社，7-8。