这个我也只能算是基本理解了,就学习曲线而言,确实不好理解和简单实现,我7月份的时候写卡在了抽象工厂,还好12份掌握了,自己做了个简单IOC的示例,觉的要基本理解IOC确实麻烦!
理解来学spring ,tp,hi,就轻松多了!
用来做项目的话,配置文件的维护确实是个麻烦?还好有CMMI的监督,否则项目开发人员走了,看的懂会飞!

>
> 这个我也只能算是基本理解了,就学习曲线而言,确实不好理?> 和简单实现,我7月份的时候写卡在了抽象工厂,还好12份掌握?> ,自己做了个简单IOC的示例,觉的要基本理解IOC确实麻烦!
> 理解来学spring ,tp,hi,就轻松多了!
>
> 用来做项目的话,配置文件的维护确实是个麻烦?还好有CMMI?> 监督,否则项目开发人员走了,看的懂会飞!

你这么说的话，配置文件维护性差到底是程序员素质问题还是spring配置文件天生的问题？
所有程序员都应该去做个3 5年trouble shooting这样的维护，而且得是大系统，之后再出来编程，看谁还不负责任。

spring是ioc的经典实现，如果是spring复杂，那我觉得没有再简单的东西了．每一样新东西出来后，都需要分析．spring也是一样．
我现在做的项目就使用spring完全可以，但在spring的基础是又封建了一层框架，感觉团队开发起了实用还方便．同时也减少了程序的错误．
我觉的spring除了集群方面．其它的都要比EJB好。

我使用spring有二年了。好东西

> 这玩意好象在csdn见过呢？
这个本来是俺写在csdn的Blog中的，后来觉得讨论的还不够，就copy在Jdon了。
单就IOC的实现而言，我认为Hivemind比Spring要强一些，它实现了bean的生命周期管理，Spring创建的bean，生命周期由JVM管理（singleton的除外），而Hivemind的bean分为singleton\pool\threadlocal\free等几种。spring的非singleton的Bean，每次都重新创建，这应该是一个性能隐患，而且，如何确定Bean是否是singleton也是费脑筋的事情。
Spring的优势在于1.有IDE支持，2.提供大量的实用的工具，比如JdbcTemplate。

到底哪里好呢？在实际应用中能解决哪些问题？
现在IOC漫天飞，
很多人连接口的实质是什么都没理解，
就开始开口闭口IOC了。
跟当年张口必谈EJB一样。

我觉得各种IOC容器的配置文件的确很复杂，但是这是必须的，因为这些东西代表了程序的逻辑。我们现在追求的是在组件内部更好的内聚性，对外更低的耦合度，那么本来应该在程序中完成的很多调用都在通过IOC容器完成了。
例子：
1:A如果调B，在程序中写死了就是调用，如果还需要调C，那么就在写一段代码调用C。
2:如果用接口实现，A调B还需要调C，B和C都实现接口I，A调用I的实现。如果再有D，就写D实现接口I，并在A的程序中调用前判断，然后调用。当然肯定需要调用统一的接口方法。但是如果接口I变化了，那么你的B，C等等都需要变化。
3:如果你说用DI，那么我想你没搞清楚DI和IOC的关系。但是根据IOC的三级理论，DI只是很初级的方式。Spring也只是实现了IOC的类型二调用方式。
4:如果用IOC容器，抛开IOC容器本身的实现，我们想加一个A调用C和D，需要写C和D的程序，将C和D注册到IOC容器。配置A需要调用哪个程序就OK了！
在配置文件中配置C和D的过程代替了在A中判断的过程。这样更灵活，配置文件本身的耦合度代替了程序的耦合度。而配置文件复杂度增大也是必然的。

任何事物都存在耦合，存在联系，这是哲学道理，IOC的使用确实降低了调用者和被调用者的耦合，但是又增加了调用者和IOC容器的耦合。