IoC 和 DI 的区别到底在哪里
可能的重复：
控制反转 <依赖注入
我总是在相同的上下文中阅读IoC（控制反转）和DI（依赖注入）。 IoC 和 DI 之间到底有什么区别？ IoC 与 DI 有何不同？
Possible Duplicate:
Inversion of Control < Dependency Injection
I always read IoC(Inversion of Control) and DI(Dependency Injection) in the same context. What is exactly the difference between IoC and DI? How does IoC differ from DI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在日常使用中，这些术语在某种程度上已成为同义词。 IoC 的最初想法——控制反转——与“好莱坞原则”密切相关：不要打电话给我们，我们会打电话给你。
在传统应用程序中，开发人员会编写业务代码和框架代码。然后业务代码将调用框架代码来完成任务。在 IoC 模型下，您“反转”该模型并创建一个接受业务模块并调用它们来完成任务的框架。这一原则在多个开发框架中得到体现，包括旧的“智能客户端软件工厂”和较新的“Prism”（或 WPF/Silverlight 的复合应用程序）。在这些模型中，UI 模块向 IoC 容器注册，并根据配置和用户操作根据需要加载。虽然功能强大，但这些模型也往往具有非常陡峭的学习曲线。
依赖注入是一种通过允许外部调用者将依赖对象注入到类/方法中来从实现中删除内部依赖关系的技术（实际上很难称之为模式）。 IoC 框架使用依赖项注入向框架例程提供用户模块和其他依赖代码，将其“粘合在一起”。 IoC 框架大量使用依赖注入，因为这是允许它们“呼叫你”的机制。
IoC 容器（例如 Castle Windsor 和 Structure Map）通过为您注册的类提供自动实例化和生命周期管理来帮助进行依赖项注入，包括自动实例化和注入注册类所需的参数。所有这些都使得使用依赖注入变得更容易，但不是必需的。
依赖注入是一种灵活性机制，可以最大化对接口的依赖，同时最小化对特定实现的依赖。因此，使用依赖注入的系统可以支持可根据情况使用的“可插入”实现类。这种“可插拔性”的一个非常大的好处是它使创建单元测试变得更加容易。您可以将对象模拟到所需的接口，然后将其注入到您的测试对象中。
因此，IoC 实际上是更广泛的原则，而 DI 是其中的一项基本技术。 IoC（好莱坞原则）系统往往相当复杂，难以理解，因此学习曲线陡峭。另一方面，DI 对于日常开发人员来说是一个很好的实践。我倾向于喜欢易于理解和清晰的，而不是冷静但复杂的。
In common usage, the terms have become somewhat synonymous. The original idea of IoC -- Inversion of Control -- was very much related to the "Hollywood Principle:" Don't Call Us, We'll Call You.
In traditional applications, developers would write business code and framework code. The business code would then call the framework code to accomplish tasks. Under an IoC model, you "invert" that model and create a framework that accepts business modules and calls them to accomplish tasks. This principle is exhibited in several development frameworks including the old Smart Client Software Factory and the newer Prism (or Composite Applications for WPF/Silverlight). In these models, the UI Modules are registered with an IoC Container and loaded as needed based on configuration and user actions. While powerful, these models also tend to have a very steep learning curve.
Dependency Injection is a technique (hard to call it a pattern, really) of removing internal dependencies from implementations by allowing dependent objects to be injected into the class/method by an external caller. IoC frameworks use dependency injection to supply user modules and other dependent code to framework routines that "glue it all together." Dependency injection is used heavily by IoC frameworks because that is the mechanism that allows them to "Call You."
IoC Containers, such as Castle Windsor and Structure Map help with dependency injection by providing automatic instantiation and lifecycle management of classes you register -- including automatic instantiation and injection of parameters required by registered classes. All of this makes it easier to use dependency injection, but is not required.
Dependency Injection is a mechanism for flexibility that maximizes dependency on Interfaces while minimizing dependency on specific implementation. Consequently, systems that use dependency injection can support "pluggable" implementation classes that can be used depending on circumstances. A very big benefit of this "pluggability" is that it makes creating Unit Tests much easier. You can mock an object to the needed interface, then inject it into your test object.
So, IoC is really the broader principle and DI is a fundamental technique within. IoC (Hollywood Principle) systems tend to be pretty complex, can be hard to understand, and thus have steep learning curves. DI, on the other hand is a good practice for everyday developers. I tend to prefer understandable and clear over cool, but complex.
IoC 是改变合同实施的能力。
DI是提供实施的能力。
IoC is the ability to vary the implementation of a contract.
DI is the ability to supply the implementation.