Spring带来的问题

          Spring对接口与实现进行了解耦，它是工程的粘合剂，同时也变成了最大的耦合剂。过多bean的配置和更加多的bean属性的配置，产生的结果是你的工程牢牢的依赖于spring。一旦失去了spring，工程就是一盘沙子(耦合性很低，可是不能运行)。Bean的配置就像在spring在块土地上种树。一个bean一颗树。但是由于命名的限制，spring的这块土地面积很小。全世界用spring的人都在这个地方种树，有一天突然两个同时使用spring的工程要进行整合。这时候发生了可怕的问题，两颗树同一个坑。当然这个问题在多配置文件的框架里都存,包括hiberante,webwork(有命名空间)等，只是spring比较突出,因为它功能大，什么都能配。而且由于使用了spring你必须把关注点分成两部分，java类文件和配置文件，spring过于强大，我们把很多类的初始化属性，类的默认方法调用都交给了它，这是候它已经不仅仅是纯粹类的粘合，而是业务的粘合。你要看懂业务你就要了解配置。配置文件的低级错误不像类的错误很容易被IDE发现，就像以前用文本编辑器来写C语言，必须通过编译才能知道错误。错误是必然存在的，谁能保证一次编写没有错误。IDE保证了100%无语法错误。Spring 到底带来了什么，修改一个接口的实现只需要修改配置，统一实现AOP。本来我们就在使用AOP，很多地方都在用，象servlet的过滤器，action的doafter()dobefor()等。Spring整合了这一切，spring很随和，它什么都可以不管，也什么都可以管。因为我们把类交给spring托管，它就是一个对象容器。它可以做很多的服务。思想很好。