我已经阅读了许多线索来解释 IoC 和 DI 之间的区别，虽然许多解释相互矛盾，但我认为它们仍然帮助我理解其中的差异 .
所以在这里我想问一下我的理解是否正确，并且发布了有助于我的摘录（虽然其中一些相互矛盾） .
我知道在这个问题上已经有很多线程，但我希望这个线程不会被关闭，因为我不认为提到的线程中的任何OP也显示所有相关的帖子（来自各种线程）他们终于明白了 .
无论如何，这是我理解的方式（如果可能，请单独解答/回答每个问题）：
a）当我们在框架级应用 DIP 原则时，我们使用术语 IoC ？在框架级实现 DIP 的机制之一是 DI ？
b）当我们在较低级别/非框架级别实现 DIP （使用 DI ）时， IoC 这个术语不适用，在这种情况下我们简称为 DI ？
c） DI 通过将实际创建和选择依赖关系的控制权传递给第三方来帮助我们实现 DIP ，第三方对所涉及的其他2个中立方是中立的？
d）当在框架级（IoC）应用 DIP （使用 DI ）时，三种类型的控制被反转：
-
The control of the interface. 现在高级模块正在控制低级模块需要遵守的接口而不是相反的方式
-
The control of the flow. - >现在框架代码（而不是用户/业务代码）控制程序的流程（换句话说 - 它们（即框架）调用你（即业务代码））
-
The control of dependency creation . 这种反转将实际创建和选择依赖关系的控制权传递给第三方，该第三方对所涉及的其他2个中立方是中立的 .
e）当在非框架级别应用 DIP （使用 DI ）时，两种类型的控件将被反转：
-
The control of the interface. 现在高级模块正在控制低级模块需要遵守的接口而不是相反的方式
-
The control of dependency creation . 这种反转将实际创建和选择依赖关系的控制权传递给第三方，该第三方对所涉及的其他2个中立方是中立的 .
？
以下摘录有助于：
Why so many terms to say the same thing? IoC and DIP
控制反转是通用术语 . 依赖注入是一种特定类型的IoC ...控制反转是指框架/基础设施调用应用程序代码，而不是相反...可以在不执行IoC的情况下执行DI . 如果你将一个ConcesoleStringWriter注入到HelloWorld中，我并不认为这是IoC，因为没有“框架”或“基础架构” .
Inversion of Control < Dependency Injection
如果你接受Fowler的定义，Inversion of Control是一个比DI更广泛的术语，涵盖了插入框架的所有框架使用，但框架仍在控制之中 . 依赖注入是IoC的一个专门化，它专门用于管理依赖关系 .
Where exactly is the difference between IoC and DI
IoC是改变 Contract 执行的能力 . DI是提供实施的能力 . ...在传统应用程序中，开发人员会编写业务代码和框架代码 . 然后，业务代码将调用框架代码来完成任务 . 在IoC模型下，您“反转”该模型并创建一个接受业务模块并调用它们来完成任务的框架 . 依赖注入是一种通过允许依赖对象从实现中删除内部依赖性的技术（很难称之为模式）由外部调用者注入类/方法 . IoC框架使用依赖注入将用户模块和其他依赖代码提供给“将它们粘合在一起”的框架例程 . 依赖注入被IoC框架大量使用，因为这是允许它们“呼叫你”的机制 .
DIP是指导我们走向DI的原则 . 基本上，松散耦合是目标，并且至少有两种方法可以实现它 . •依赖注入•服务定位器
Does anyone have a good analogy for dependency injection?
控制反转的本质（其中依赖注入是一种实现）是对象的使用与其管理的分离 .
Difference between ioc and dependency injection
术语依赖注入（DI）＆控制反转（IoC）通常可互换地用于描述相同的设计模式（尽管并非所有人都同意这一点，并且有些人倾向于以稍微不同的方式应用它们） . 该模式最初称为IoC，但Martin Fowler建议转向DI，因为所有框架都以某种方式反转控制，他希望更具体地说明控制的哪个方面被颠倒了 .
Inversion of Control vs Dependency Injection
控制反转（IoC）意味着对象不会创建他们依赖的其他对象来完成工作 . 相反，他们从外部源获取所需的对象（例如，xml配置文件） . 依赖注入（DI）意味着这是在没有对象干预的情况下完成的，通常由传递构造函数参数和设置属性的框架组件完成 .
谢谢
2 回答
那么这是我的观点：
DIP 表示您针对抽象进行编程 . 您可以将依赖项的类型从实现转换为抽象 .
IOC 表示其他人负责获取给定抽象的实现 . 通常，消费者会使用 new 关键字来获取依赖关系 . 使用IoC，您可以反转控件，这样消费者就不再负责创建实例了 .
Dependency Injection 和 Service Location 是 Inversion of Control 的一部分 .
另见：https://stackoverflow.com/a/10053413/175399
我已经在我的[博客]中写了差异：http://dotnet-stuff.com/tutorials/dependency-injection/dependency-inversion-principle-dependency-injection-and-inversion-of-control-dip-ioc-and-di "click here for updates"我们如何组织控制反转，依赖倒置原则和依赖注入 . 简而言之，我们可以说 -
最重要的是依赖倒置原则，这是一种设计软件的方法 . 它没有说如何制作独立的模块 . 控制反转（IoC）提供了应用DPI原理的方法 . 但是IoC仍然没有为我们提供具体的实现 . 它提供了一些方法，以便我们可以反转控件 . 如果我们想要使用Binding inversion或依赖项创建来反转控制，那么我们可以通过实现依赖注入（DI）来实现它 .