如何解决控制反转与依赖注入
)模式是关于提供任何种类callback的（“实现”和/或控制反应），而不是直接行动（换句话说，反转和/或将控制重定向到外部处理程序/控制器）。
模式的更具体版本，其中实现通过构造函数/设置器/服务查找传递给对象，对象将“依赖”这些查找以正确运行。
每个
DI实现都可以考虑IoC，但不应该调用它IoC，因为实现依赖注入比回调更难（不要通过使用通用术语“IoC”来降低产品的价值）。
将是模板模式，因为只能通过子类化来更改实现。
旨在利用 DI，并且可以定义接口（或 Java 中的 Annotations）以使其易于传递实现。
是可以在编程语言之外工作的 DI 框架。在某些情况下，您可以配置在侵入性较小的元数据文件（例如 XML）中使用哪些实现。有了一些你可以做 IoC，这通常是不可能的，比如在pointcuts注入一个实现。
解决方法
根据Martin Fowler
撰写的论文，控制反转是程序控制流反转的原理：不是程序员控制程序流，而是外部源（框架、服务、其他组件）控制它。就像我们将某些东西插入到其他东西中一样。他提到了一个关于
EJB 2.0 的例子：
例如，会话 Bean 接口定义了 ejbRemove、ejbPassivate（存储到辅助存储）和
ejbActivate（从被动状态恢复）。您无法控制何时调用这些方法，而只能控制它们的作用。容器呼叫我们，我们不呼叫它。
这导致了框架和库之间的区别：
控制反转是使框架与库不同的关键部分。库本质上是一组可以调用的函数，现在通常组织成类。每个调用都会做一些工作并将控制权返回给客户端。
我认为，DI 是 IOC 的观点意味着对象的依赖关系是倒置的：它不是控制自己的依赖关系，而是生命周期......其他东西会为你做。但是，正如你亲手告诉我的
DI，DI 不一定是 IOC。我们仍然可以有 DI 而没有 IOC。
然而，在这篇论文中（来自 pococapsule，另一个 C/C 的 IOC 框架），它表明由于 IOC 和 DI，IOC 容器和 DI 框架远优于
J2EE，因为 J2EE 将框架代码混合到组件中，因此不会使其成为普通的旧 Java/C 对象 (POJO/POCO)。
依赖注入模式以外的控制容器的反转 （存档链接）
附加阅读以了解旧的基于组件的开发框架有什么问题，这导致了上面的第二篇论文：
控制反转的原因和内容
（存档链接）
我的问题 ：IOC 和 DI 到底是什么？我很迷惑。基于 pococapsule，IOC 不仅仅是对象或程序员与框架之间的控制反转更重要的东西。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
