究竟为什么我们要用Spring

Spring做为一个优秀的框架被很多人推崇，当然，在这些人中并不是全部，或者可以说是其中的相当一部分并不是真正了解Sping的优点，只是大家认为它好，就说它好。那么究竟Sping到底好在哪呢？说它可以和很多框架无缝的连接在一起，感觉很通用，这确实是它的优点。不过对于struts和hibernate来说，我不使用spring也是一样可以完成整合，而且它们之间也不会产生什么矛盾，那么为什么我非要弄出来一个什么SSH三个框架整合到一起去呢？这个问题也有好多人提出过。那也就是对于为什么要使用Spring产生了疑问。

首先我们要先明确一点，由于加入了很多的Support，比如说JdbcDaoSupport等，Spring对于项目的代码编写来说简单很多，但是由于项目中的dao和service都要交给spring的bean容器管理，有时候可能action也交有bean容器管理，那么对于spring的配置文件来说，编写就显得过于复杂，需要很多的bean。虽然JAVA编码减少了，但是大部分的时间程序员都在和复杂的配置文件做斗争。由此可见，项目中加入spring并不是向一些人说的提升了开发效率，所以把提升开发效率作为spring的优势来说有些勉强。

那么为什么我们还要提倡使用spring呢？我认为spring由bean容器管理带来的优势和一些动态代理的实现对于我们项目系统框架的搭建起着非常重要的作用，Spring的AOP更是独放异彩。

比如说我们把action交给spring管理，那么我们就可以在bean容器中改变action的单例非线程安全的模式，可以把它变成一个原形（非单例）模式。比如我们需要对action进行一下访问记录，在action我们设置一个私有属性，保存一些信息，每个用户进入action后都对这个私有属性进行一下设置，比较加入一些用户独有的特殊标志。但是由于action本身就是单例模式，这样就造成了所有用户操作的都是同样一个action，对同一个属性进行操作，而且action本身就是非线程安全的，那么很有可能张三的属性在没有具体操作之前就被李四改掉了。这样就非常危险了，那么如果通过spring的bean容器管理以后就可以刨除这个缺陷，它可以通过spring的bean容器的特性来设定其scope范围由默认的singleton变成prototype模式，这样就可以对每次访问都产生一个新的action来处理，避免了这样的错误产生。对于这样的表现层框架，我们可以不通过改变其原代码就能控制它的生命周期来讲是非常激动人心的。而且spring提供了很多的动态代理类可以让我们去实现诸如声明式事物控制，action管理，AOP等强大功能。对于AOP来说，我们可以不用去手写一个动态代理类就可以实现横切逻辑的准确织入，可以随意去把我们的代码拆分开；甚至可以想象一下，我们的项目都可以拆分成一个小块一个小块的，然后依靠横切逻辑随意织入，当然，对于项目本身而言，它内部的逻辑大多数情况下是不可拆分的。不过对于系统性能监测或者是事物这些东西来说，本身就是可重复定义在多个业务逻辑上面的，所以他们使用Sping AOP操作起来就非常的舒服。而且spring2.0加人了很多的AOP增强，可以通过tx/aop命名空间进行声明式事物控制，甚至通过对元数据的支持可以更加简单的实现事物管理，还可以通过引介增加来动态控制一些事物的进展情况，比如人为控制系统性能检测日志的开启和关闭。所以Spring在系统框架集成方面作出的贡献是不可替代的。

最后说一下Spring是非常优秀的框架，如果你只把它看成是提升开发效率的工具，那么你大可以不必使用它，因为它本身对开发效率来讲并没有提升很多，往往因为它的加入范围复杂了开发流程，service,dao中的实现类和接口必须分开，因为Rod 本人比较推崇面向接口编程。使用它是在写诗，是在完成一项伟大的杰作，可以说spring是java所有框架中最优秀的一个。它让我们认识到了java这个广大领域中那些深层次的知识，它让我们的思想更加成熟，对于项目框架的控制更加灵活。 :arrow: