Inversion of Control vs Dependency Injection
According to the paper written by Martin Fowler: http://martinfowler.com/bliki/InversionOfControl.html , inversion of control is the principle where the control flow of a program is inverted: instead the programmer controls the flow of a program, the external sources (framework, services, other components) take control of it. It likes we plug something into something else. He mentioned an example about EJB 2.0:

> 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.

This leads to the difference between framework and library:

> 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.

I think, the point of view DI is IOC, means the dependency of an object is inverted: instead it controls its own dependencies, life cycle... something else does it for you. But, as you told me about DI by hands, DI is not necessary IOC. We can still have DI and no IOC.

However, in this paper (from the pococapsule, another IOC Framework for C/C++), it suggests that because of IOC and DI, the IOC containers and DI frameworks are far more superior to J2EE, since J2EE mixes the framework code into the components, thus not making it Plain Old Java/C++ Object (POJO/POCO).

**Inversion of Control Containers other than the Dependency Injection pattern**: http://www.pocomatic.com/docs/whitepapers/ioc-vs-di/

Additional reading to understand what's the problem with old Component-Based Development Framework, which leads to the second paper above: **Why and what of Inversion of Control**: http://www.pocomatic.com/docs/whitepapers/ioc/
Inversion of Control vs Dependency Injection
===

According to the paper written by Martin Fowler: http://martinfowler.com/bliki/InversionOfControl.html , inversion of control is the principle where the control flow of a program is inverted: instead the programmer controls the flow of a program, the external sources (framework, services, other components) take control of it. It likes we plug something into something else. He mentioned an example about EJB 2.0:

> 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.

This leads to the difference between framework and library:

> 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.

I think, the point of view DI is IOC, means the dependency of an object is inverted: instead it controls its own dependencies, life cycle... something else does it for you. But, as you told me about DI by hands, DI is not necessary IOC. We can still have DI and no IOC.

However, in this paper (from the pococapsule, another IOC Framework for C/C++), it suggests that because of IOC and DI, the IOC containers and DI frameworks are far more superior to J2EE, since J2EE mixes the framework code into the components, thus not making it Plain Old Java/C++ Object (POJO/POCO).

**Inversion of Control Containers other than the Dependency Injection pattern**: http://www.pocomatic.com/docs/whitepapers/ioc-vs-di/

Additional reading to understand what's the problem with old Component-Based Development Framework, which leads to the second paper above: **Why and what of Inversion of Control**: http://www.pocomatic.com/docs/whitepapers/ioc/