控制反转与依赖注入
根据Martin Fowler撰写的论文，控制反转是程序控制流程颠倒的原则：代替控制程序流程的程序员，外部源（框架，服务，其他组件）控制它。 这就像我们将东西插入其他东西。 他提到了一个关于EJB 2.0的例子：
例如，Session Bean接口定义了ejbRemove，ejbPassivate（存储到辅助存储）和ejbActivate（从被动状态恢复）。 当这些方法被调用时，你无法控制，只是他们做了什么。 容器打电话给我们，我们不叫它。
这导致了框架和库之间的区别：
控制反转是使框架与图书馆不同的关键部分。 库本质上是一组可以调用的函数，这些函数通常组织成类。 每次通话都会执行一些操作并将控制权返回给客户端。
我认为，DI是IOC的观点意味着一个对象的依赖性被颠倒过来：相反，它控制着它自己的依赖关系，生命周期......别的东西为你做了。 但是，正如你用手告诉我的DI，DI不一定是IOC。 我们仍然可以拥有DI和没有IOC。
然而，在本文中（来自pocoapsule，另一个IOC Framework for C / C ++），它表明由于IOC和DI，IOC容器和DI框架远远优于J2EE，因为J2EE将框架代码混合到组件中，因此不会使它成为普通Java / C ++对象（POJO / POCO）。
除了依赖注入模式之外的控制容器的反转 ：http://www.pocomatic.com/docs/whitepapers/ioc-vs-di/
补充阅读，了解旧的基于组件的开发框架的问题，这导致了上面的第二篇论文： 为什么和控制反转 ：http://www.pocomatic.com/docs/whitepapers/ioc/
我的问题 ：IOC和DI究竟是什么？ 我很困惑。 基于pococapsule，IOC比仅仅反转对象或程序员和框架之间的控制更重要。
IoC是一个通用的术语含义，而不是具有应用程序，调用框架中的方法，框架调用应用程序提供的实现。
DI是IoC的一种形式，通过构造函数/设置程序/服务查找将实现传递到对象中，对象将“依赖”以便正确运行。
例如， 不使用DI的IoC就是模板模式，因为只能通过子分类来更改实现。
DI框架旨在使用DI，并可定义接口（或Java中的注释），以便轻松传递实现。
IoC容器是可以在编程语言之外工作的DI框架。 在某些情况下，您可以配置哪些实现在元数据文件（例如XML）中使用，这些文件的侵入性较小。 通过一些你可以做的IoC，这通常是不可能的，就像在切入点注入实现一样。
另请参阅Martin Fowler的文章。
总之，IoC是一个更广泛的术语，包括但不限于DI
控制反转（IoC）这个术语最初意味着任何类型的编程风格，其中总体框架或运行时间控制程序流程
在DI有了名字之前，人们开始将控制依赖的框架称为控制容器的反转，并且很快，IoC的意义逐渐转向了这个特定的含义：控制对依赖的反转。
控制反转 （IoC）意味着对象不会创建其他依赖其执行工作的对象。 相反，他们从外部源获取他们需要的对象（例如，xml配置文件）。
依赖注入 （DI）意味着这是在没有对象干涉的情况下完成的，通常是通过构造函数参数和设置属性的框架组件完成的。
DI是IoC的一个子集
以下是一些实现IoC的其他技术。
链接地址: http://www.djcxy.com/p/2323.html