关于Ioc的思考

　　这几天都在研究Ioc的实现项目：google的guice。现在被网上炒作的很严重，有取代spring的趋势。看了很多网站写的这两个Ioc的项目比较，都夸guice的速度如何好。

　　细细想来，其实这两个产品都是Ioc的实现，只是实现的思想不同罢了，有和优劣可言呢!

　　spring其实是个非常好的Ioc实现，好在当Java的开发停留在工厂模式下的时候，突然有这个一个Ioc的实现，让所有的软件开发人员都为之惊叹。记得在很早以前，我们开发小组的头，就使用过这种通过Xml配置注射方式来加载不同的实现类。但没有提出一整套的解决方案。现在想想，不是中国人的智慧少，而是中国人没有意识将一些好的创业产品化。

　　话说远了，但重听。其实Ioc就是个分离各层的解决方案，说复杂其实一点都不复杂。它的实现，使得软件的层与层之间的耦合更加的松散，更加的符合大型项目的开发和管理。也使得AOP的设计思路能够实现。

　　spring在初期也是得到大家的追捧，guice刚开始起步，不知道能到什么时候。spring使用xml配置的方式缺点越来越多的暴露出来，因为一个项目开发出来后不可能去现场修改其实现的子类。也就是说xml的灵活性在项目开发出来后成为了项目维护的累赘。由于层与层之间的关系已经不是很明显，在加上国人非常不喜欢写文档和注视，为后续的维护增加了困难。

　　guice采用的是java 5的标注方式，其注入可以说更加隐蔽，软件代码的层分离的更加松散。虽然通过binder能够找到它们之间的关系，但也是被guice实现后隐藏。要迅速把握系统的脉搏，就要有比较扎实的功底。另一方面，guice有个先天不足，就是它不可能在jdk1.3等低版本下工作。不要说今天那还有这样的项目啊，实际的情况会出现的。

　　所以说如果从项目角度来说，如果你的项目只有几个人就能搞定，都可以不使用这些花哨的架构。当然，从维护性来说，还是使用spring的为好，因为现在懂spring的人多，即使项目组有人离开，也能很快有人接手。

　　说了这么多，还是强调一点，思想才是重要的，技术只是辅助!