IoC和DI之间的区别到底在哪里[重复]

Question

可能重复：
Inversion of Control < Dependency Injection

我总是在相同的上下文中阅读 IoC（控制反转）和 DI（依赖注入）。 IoC 和 DI 之间到底有什么区别？ IoC 与 DI 有何不同？

Answer 1

在通常的用法中，这些术语已成为同义词。 IoC 的最初想法——控制反转——与“好莱坞原则”密切相关：不要打电话给我们，我们会打电话给你。

在传统应用程序中，开发人员会编写业务代码和框架代码。然后业务代码将调用框架代码来完成任务。在 IoC 模型下，您“反转”该模型并创建一个接受业务模块并调用它们来完成任务的框架。这一原则体现在几个开发框架中，包括旧的智能客户端软件工厂和新的Prism（或 WPF/Silverlight 的复合应用程序）。在这些模型中，UI 模块在 IoC 容器中注册，并根据配置和用户操作按需加载。这些模型虽然功能强大，但也往往具有非常陡峭的学习曲线。

依赖注入是一种通过允许外部调用者将依赖对象注入到类/方法中来从实现中移除内部依赖的技术（实际上很难称之为模式）。 IoC 框架使用依赖注入来向框架例程提供用户模块和其他依赖代码，从而将它们“粘合在一起”。 IoC 框架大量使用依赖注入，因为这是允许它们“呼叫您”的机制。

IoC 容器（例如 Castle Windsor 和 Structure Map）通过为您注册的类提供自动实例化和生命周期管理（包括注册类所需参数的自动实例化和注入）来帮助依赖注入。所有这些都使得使用依赖注入变得更容易，但不是必需的。

依赖注入是一种灵活性机制，可以最大限度地增加对接口的依赖，同时最大限度地减少对特定实现的依赖。因此，使用依赖注入的系统可以支持可根据情况使用的“可插入”实现类。这种“可插入性”的一个非常大的好处是它使创建单元测试变得更加容易。您可以将对象模拟到所需的接口，然后将其注入到您的测试对象中。

因此，IoC 实际上是更广泛的原则，而 DI 是其中的一项基本技术。 IoC（好莱坞原则）系统往往非常复杂，难以理解，因此具有陡峭的学习曲线。另一方面，DI 对日常开发人员来说是一种很好的实践。我倾向于更喜欢可以理解和清晰而不是酷但复杂的。

Answer 2

IoC 是改变合同实施的能力。

DI 是提供实现的能力。