IOC, huh?

还是没想明白！
照楼上所说，组件不应该知道有容器的存在，那如何解决这个问题：
类CRMAccount的方法getRecentList中需要动态构造对象Query，
而Query需要SessionFactory对象，那在getRecentList中如何来
得到这个Query对象呢？因为按规则它是不能知道有容器的，那如何IOC
出一个Query对象呢？

看。我说吧。弄得好像我在这大喊：“中华人民共和国成立了”一样。

多少人都是见到一个大家说好的工具，如pico/spring，马上迫不及待地把它们放在自己的所有可以想到用它们的地方，完全不知道自己其实是在背道而驰。

不管什么工具，只要你直接调用它，你就是面向实现，面向具体，不再是ioc，即使这是一个ioc工具。

程序中当然要有地方面向具体，面向实现，但是这个地方要单一，这样面向具体的代码要减少到最小程度。

象那个DeptDao和EmplDao的例子。

我还是喜欢用构造函数注射，原因在于用setter的话人为增加不必要的中间状态。没办法,一个成员变量如果不是final的我就难受. (用java 1.2的时候我这个癖好让我们project很吃了点苦头: jdk1.2对final成员的支持有bug,会他娘的编译甚至运行时出错!)



楼上的，给个代码例子吧，不是很明白你的需求。

不过，有个小提示：在你没有pico/spring这些奶妈的时候，你怎么描述这个需求？

我不是说pico没有用，在最顶层组装对象（通过代码／xml文件等）还是很有用的。问题是在子组件一级上，平行的组件之间如何相互构造。

不要构造.用ioc!

在组件中用ico不是违反了组件不应该知道容器的规则，且容器对象由哪来呢？

唉.这就是我要说的呀: ioc和容器是不搭界的两样东西.
所谓ioc,说起来非常简单.

面对问题:
要实现一个功能, 这个功能需要从别的模块获得一些服务(比如获得一个对象持久化功能).

解决方法:
1. 定义一个persistence接口.
2. 在实现这个功能的模块声明一个Persistence类型的变量.(最好final)
3. 从构造函数传递进来.
4. 直接用这个Persistence变量.

这就是ioc了.跟容器八竿子扯不上.

我得说，必须承认ajoo的担心确实是很现实存在的，存在的广泛程度甚至超过我的猜想。“问题是在子组件一级上，平行的组件之间如何相互构造”——构造个什么劲呢？你要用哪个组件，就通过“某种方法”把这个组件拿到，这个“某种方法”可以是构造子也可以是setter，总之你就当那个组件已经有了，你只管用就是了嘛。到最后我们总有办法把这个真正的组件拿给你，这才是容器的作用。

hehe,平行的组件相互构造，这句话有语病啊。
首先是什么叫平行，第二怎么个叫相互构造。不太理解。

我的总结：

ioc的美德就是一个字：懒。

每个模块只关心自己那一点点功能。遇到须要别的功能的，什么是最简单的办法？
狮子大开口，定义一个接口，说：我要这个功能。
然后要求构造函数传递进来就行了。

有比这更省事的吗？为什么我们的程序员总是学不会懒惰呢？

多年的面向过程，面向实现的训练让他们遇事都是老老实实地想着直接去解决。从来没有想过有时候做一件事情比不做一件事情糟糕得多！

仔细阅读了Spring的文档的话，应该不会有楼主所担心的情况发生。实际情况是Spring和Pioc的出现让IOC得到了推广，但从楼主的文字看去好像在批判Spring和Pioc似的，呵呵，到底楼主是想表达一个怎样的意思呢？