看部电影，透透彻彻理解IoC(你没有理由再迷惑!)

很好，准备开始学习spring。。。

有一点我比较疑惑，“IoC的概念大于DI，可以说DI是IoC” ，“IoC的概念更为宽泛，但它绝不是DI！DI也不是用来代替IoC的，DI是Martin Fowler之后定义出来用以描述那些所谓实现了IoC的Container的一种Pattern”，那ioc除了di这个pattern，还有其他哪些pattern？

   Martin Fowler说IoC和DI不是同一个级别的概念，IoC就象“动物”，而DI是“马”一样：而IoC是一种思想或一种现象（如他举的那个例子：用户在操作UI时，其实控制是在服务端）比较宽泛，而DI是一个设计模式，相对来说，概念比较窄。只要理解了这一点，你的问题就清楚了。

这个不是《Spring 3.x 企业应用开发实战》 的例子吗

楼主就是陈雄华?

  当然是了，帖子后面不是有写了 ：

正解！比喻也很到位！

按照我的理解，IoC这个词被创造出来的时候，可能是为了解决在程序的运行过程中，对象与对象的协作问题。

按照martin fowler的观点：一个复杂的程序逻辑，总不能始终在某一个具体对象的某一个方法中一竿子到底，而是需要对象和对象之间的协作来共同实现逻辑目标。而对象和对象之间的协作，有许多中协作方式，其中最为廉价的一种方式，就是在一个对象中的属性变量中引用另外一个对象来完成。这种对象间的协作模式的引用，会造成对象生命周期管理上的困惑：A引用了B，A理应负责B的创建啊。是的！不过将B的生命周期的管理交给A来做，势必造成对A固有程序逻辑的入侵，从而造成了一系列不可预知的维护困境。在这种情况下，我们可以借助一个与A和B都无关的第三方来完成整个工作，目前最为流行的第三方就是“容器”，例如Spring容器，XWork容器等等。如果仔细看楼主的例子，可以发现楼主这个例子其实向大家说明的是“容器”这个元素到底是如何引入的。

而一旦有一个这样的容器，它控制着所有对象的生命周期，就相当于我们的应用程序运行在这个容器之中。此时，这个容器看上去就有点像一个Framework，我们的应用程序，就如同被Framework这个幕后的推手控制着。这其实应该就是martin fowler所说的IoC所描述的应用程序和Framework之间的配合。具体可以参看我之前列出来的英语原文，里面有比较详细的描述。

呵呵，我主要想表达的是，IOC这个动物我看到了，DI这个(白)马我看到了，但是其他马呢?
去掉了那些复杂概念，IOC/DI的本质就是在配置文件（或通过注解）描述对象之间的引用关系。。。
其实，我更欣赏spring的AOP能力；实际编程时，只在一个接口可能具有多个实现时，我才愿意使用ioc，其他基本不用。。

能说出最后一句话，只能说明你对IoC的概念还完全没有理解。

呵呵,嗯,所以我是看着LZ的"你没有理由再迷惑"标题进来的
当然,你的意思我理解一下,应该是指对象之间的依赖如果通过spring管理,会在日常开发中带来其他的方便/红利吧(不仅仅是对 对象的依赖关系管理那么简单).