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 Containers，例如Castle Windsor和Structure Map通过提供自动实例化和您注册的类的生命周期管理来帮助依赖注入 - 包括自动实例化和注册类所需的参数注入。所有这些都使得更容易使用依赖注入，但不是必需的。

依赖注入是一种灵活性机制，可最大限度地减少对接口的依赖，同时最大限度地减少对特定实现的依赖性。因此，使用依赖注入的系统可以支持可根据环境使用的“可插拔”实现类。这种“可插拔性”的一个非常大的好处是它可以更轻松地创建单元测试。您可以将对象模拟到所需的接口，然后将其注入测试对象。<​​/ p>

因此，IoC确实是更广泛的原则，DI是其中的基本技术。 IoC（好莱坞原则）系统往往相当复杂，难以理解，因此具有陡峭的学习曲线。另一方面，DI对于日常开发人员来说是一个很好的做法。我倾向于更容易理解和清晰，但很复杂。

Answer 2

IoC能够改变合同的实施。

DI是提供实施的能力。