For example the Session Bean interface
defines ejbRemove,ejbPassivate
(stored to secondary storage),and
ejbActivate (restored from passive
state). You don’t get to control when
these methods are called,just what
they do. The container calls us,we
don’t call it.
这导致框架和库之间的区别：
Inversion of Control is a key part of
what makes a framework different to a
library. A library is essentially a
set of functions that you can call,
these days usually organized into
classes. Each call does some work and
returns control to the client.
我认为，DI是IOC的观点，意味着一个对象的依赖被反转：它控制自己的依赖，生命周期…别的什么为你。但是，当你告诉我关于DI的手，DI不一定是IOC。我们仍然可以有DI和没有IOC。
然而，在本文(来自Pococapsule，另一个IOC框架的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是更重要的，而不仅仅是反转对象的控制或在程序员和框架之间。
DI是IoC的一种形式，其中实现通过constructors / setters / service查找传递到对象，对象将依赖它来正确地运行。
IoC没有使用DI，例如将是模板模式，因为实现只能通过子类改变。
DI框架旨在利用DI，并且可以定义接口(或Java中的注释)，以便于在实现中传递。
IoC容器是DI框架，可以在编程语言之外工作。在某些情况下，您可以配置在元数据文件(例如XML)中使用哪些实现，这些实现是侵入性较小的。有些你可以做IoC通常是不可能的注入实现在pointcuts。
参见http://martinfowler.com/articles/injection.html#InversionOfControl
