dependency-injection - IoC和DI到底有什么区别

Question

<分区>

Answer 1

在通常情况下，这些术语在某种程度上已成为同义词。 IoC 的最初想法——控制反转——与“好莱坞原则”密切相关:不要调用我们，我们会调用你。

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

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

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

依赖注入(inject)是一种灵 active 机制，它可以最大化对接口(interface)的依赖，同时最小化对特定实现的依赖。因此，使用依赖注入(inject)的系统可以支持可根据情况使用的“可插入”实现类。这种“可插入性”的一个非常大的好处是它使创建单元测试变得更加容易。您可以模拟一个对象到所需的接口(interface)，然后将其注入(inject)您的测试对象。<​​/p>

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