Spring2.0的新特性点评

Spring2.0的发布恐怕算得上2006年Java社区的一件大事了。在Spring2.0发布附带的文档里面对2.0新特性做了概要的介绍，2.0的新特性是自然是我们最关注的方面：

一、Spring的XML配置引入XML Schema语法简化配置

在Spring1.x系列中，bean的配置文件使用DTD，没有namespace的分隔。2.0的一个非常大的改进是引入了XML Schema的namespace，因而可以将bean的配置文件做大幅度的简化。这些简化包括了对bean属性的各种简化，AOP配置的简化，事务配置的简化，JNDI配置的简化等方面。当然，在简化配置的同时，新的XML Schema实际上引入了更多的XML语法，因此使用一个支持XML Schema的XML Editor就显得非常必要了，例如Eclipse WTP就可以提供Schema的语法自动提示和校验功能。

Spring1.x的bean配置文件逐渐复杂烦琐化，是Spring历来被人所垢病的主要问题之一。在Spring2.0里面XML Schema语法的配置可以在相当程度上降低配置文件的复杂程度和烦琐程度，可以视为Spring的重大改进之一。但是我们也必须看到XML Schema并没有从根源上面解决XML配置复杂的问题，而只是减轻。

将所有的bean之间的依赖关系，组装关系统统使用XML来描述，本身就会导致XML阅读和修改一定的困难。并且用XML配置本身无法直接进行单元测试来验证依赖关系。因此，当bean之间关系越复杂的时候，XML配置文件本身的维护也是一个负担。

我个人比较期待未来的Spring能够使用脚本语言来编写和组装bean之间的关系，这样组装脚本本身也是可测试的，而且脚本的描述能力要远远好于XML配置文件，同时编写和维护起来也比XML轻松。


二、提供了request和session范围的bean

引入request scope和session scope的bean，我感觉是把双刃剑。对于普通的Java Web框架应用来说，和Servlet容器相关的操作应该限制在Web层，对于业务层来说，不应该涉及request和session的scope，否则业务层代码无法脱离Servlet容器进行单元测试。对于使用Webwork/Struts框架的用户来说，恐怕不太会使用该特性，另外根据我的理解，也许request/session scope的bean也是为了提供给Spring MVC的Controller使用的。

除此之外，对于AJAX Web Service调用来说，这一特性反而是很有用处的。对于这种应用场景，JS通过AJAX调用，抛开Web层框架，直接访问业务层bean，这个时候就需要提供request/session scope的bean了。


三、集成AspectJ，可以管理容器外对象，提供了领域模型的依赖注入

通常由Hibernate管理的持久化对象PO，并不是由Spring容器初始化的，往往是用户自己new出来，或者通过find，load方法创建的，其结果就是Spring容器无法对这种容器外创建的对象进行bean依赖关系注入。

在Spring2.0中，可以使用AspectJ对领域模型进行静态织入，这样当该领域模型在容器外被创建的时候，会产生对容器的回调，进行依赖关系的注入。

Spring2.0提供的这一特性，确保了Martin Folwer的Rich Domain Object的可行性，这一特性的提供恐怕会对未来很多Java系统的设计产生相当深远的影响。

其实针对Rich Domain Object更进一步，如果将DAO功能作为Domain Object的抽象父类，那么持久化对象PO就会集PO，DAO，Service对象于一身，整个业务层，持久层完全合并为一个对象，通过这种方式进行框架简化得到的结果就是，高度类似于ruby on rails的full-stack的MVC框架。


四、JPA支持

这一点其实没有什么可点评的，提供JPA支持本来就是理所应当之事。


五、JDBC的NamedParameterJdbcTemplate

NamedParameterJdbcTemplate我认为意义非凡，为JDBC查询提供了带命名参数的占位符，而不止是JDBC自己的“？”，这样使用JDBC的时候，也可以很容易的构造出来带占位符的动态条件查询，而不是参数值带入方式的拼接SQL字符串了。


六、Spring Web MVC功能的大幅度扩充

看的出来，在Spring2.0里面 Web MVC功能大幅度扩充，过去不提供的UI Taglib也终于提供了，配置文件也进行了必要的简化。虽然Spring MVC从框架设计角度来说远远不如Webwork那么有创意，但是也是一步一个脚印的改进，再配合上各种外围框架例如Spring Webflow等的支持，可以预见Spring MVC会成长为Webwork的劲敌。


七、支持动态语言ruby，groovy，beanshell

动态语言支持目前看来还比较简单，不够强大，但是表明了Spring的一个态度，其实我个人希望Spring能够加强这方面支持，甚至大胆一点，提供用动态脚本语言编写的bean组装配置。


八、异步JMS支持，JMX支持，JCA支持的功能完善

Spring2.0自身提供了两类简单的JMS Containter，此外还提供了外部JMS Server的接口，另外JMX功能的支持，JCA功能的支持都在进一步的完善过程中。

Spring2.0在这几个方面的功能支持不是那么引入注目，毕竟普通Java Web应用很少使用这些方面。但是Spring提供这些功能的完善支持意义却很深远，因为这些功能都是J2EE规范所要求提供的功能，也是传统应用服务器厂商相对比Java开源框架的传统优势项目。一旦Spring2.0对这些功能提供了完善的支持，那么将传统的Java企业应用完全迁移到Spring框架上面的技术障碍就一扫而空了。

因此Spring是一个野心很大的框架，从现在状况来看，Spring可以说是Java开源框架之集大成者，从未来来看，Spring将提供J2EE厂商所能够提供的所有必要的功能，最终Spring将有可能取J2EE规范而代之，成为Java企业开发的事实平台和事实标准。

总体来说，Spring2.0将向未来的宏大目标又迈进了一大步。不过对于我等普通Java Web项目的开发需求来说，2.0的新特性也没有特别需要的。

评论

25 楼 stamen 2006-10-29  

Spring 2.0在AOP的配置上确实简化了不少，值得好好学习。

24 楼 lighter 2006-10-25  

"配置文件终究是要程序员编写，维护的，所以可维护性上面，XML比脚本语言自然差太远了。"
同意同意,有时候给spring的配置文件搞得头都大了,特别在维护旧系统的时候,看别人配置的文件的风格,有时候很别扭.

23 楼 robbin 2006-10-17  

chenxu 写道

robbin ： "而且脚本的描述能力要远远好于XML配置文件，同时编写和维护起来也比XML轻松"，

   不理解 这句话的意思。就”描述能力“来看，xml的描述能力应该是
   强于脚本的。 而且脚本的编写和维护也并不比xml轻松。

   我的理解是这个问题应该是通过一个专门的工具来进行xml的配置（用工具来解决配置的复杂性）。至于是用 xml 还是 脚本 来保存此配置，只是一个存储方式的问题。和配置的复杂性本身并
   没有什么关系。

   大家认为呢？

配置文件终究是要程序员编写，维护的，所以可维护性上面，XML比脚本语言自然差太远了。

22 楼 chenxu 2006-10-17  

robbin ： "而且脚本的描述能力要远远好于XML配置文件，同时编写和维护起来也比XML轻松"，

   不理解 这句话的意思。就”描述能力“来看，xml的描述能力应该是
   强于脚本的。 而且脚本的编写和维护也并不比xml轻松。

   我的理解是这个问题应该是通过一个专门的工具来进行xml的配置（用工具来解决配置的复杂性）。至于是用 xml 还是 脚本 来保存此配置，只是一个存储方式的问题。和配置的复杂性本身并
   没有什么关系。

   大家认为呢？

21 楼 江南白衣 2006-10-13  

Spring2.0 容易，JDK5.0 就要先等Weblogic 8.1退出历史舞台了....

20 楼 梦秋雨 2006-10-13  

只是期待，什么时候公司能用这些东西。jdk1.5 and spring2.0

19 楼 bluemeteor 2006-10-09  

iamjxc 写道

robbin提到：
其实针对Rich Domain Object更进一步，如果将DAO功能作为Domain Object的抽象父类，那么持久化对象PO就会集PO，DAO，Service对象于一身，整个业务层，持久层完全合并为一个对象，通过这种方式进行框架简化得到的结果就是，高度类似于ruby on rails的full-stack的MVC框架。

与我们讨论了很多PO/DAO/Service分层的做法不是背道而驰了吗？

我的理解是Spring2只是支持这种设计方法，尚未鼓励大家在所有的业务模型中都这样做

18 楼 Allen 2006-10-09  

Spring的易用性实在是太诱人了……

现在国内书店计算机类书架上最火的书籍里面现在又添加了“Spring”一条。 这里面应该也是有过去几年中“Struts”跟“Hibernate”大卖的因素存在（有相当多的人希望用Spring这个框框来修补自己在Struts和Hibernate开发中“捅出来的娄子”）。当然了，抱有“拿来就用、用完就算”心态的软件工程师也不在少数，兴许今后他们又要用别的什么来擦现在的PP……

AJAX也是很火的，甚至于有的同学已经跳过JavaScript的书也直接奔向AJAX的条目了……只是有关RoR的书籍目前还是没有怎么流行起来哦。

愿Spring真主仁慈地遮住我光了几年的PP吧!

17 楼 robbin 2006-10-08  

其实我到觉得用AspectJ来提供容器外bean的注入应该尽量避免使用。一来bean产生对于spring和aspectj的代码依赖，二来需要多一步静态增强操作，不利于调试。传统的做法死板到是死板一点，但是结构比较简单。

16 楼 江南白衣 2006-10-08  

robbin 写道

三、集成AspectJ，可以管理容器外对象，提供了领域模型的依赖注入

通常由Hibernate管理的持久化对象PO，并不是由Spring容器初始化的，往往是用户自己new出来，或者通过find，load方法创建的，其结果就是Spring容器无法对这种容器外创建的对象进行bean依赖关系注入。

在Spring2.0中，可以使用AspectJ对领域模型进行静态织入，这样当该领域模型在容器外被创建的时候，会产生对容器的回调，进行依赖关系的注入。

Spring2.0提供的这一特性，确保了Martin Folwer的Rich Domain Object的可行性，这一特性的提供恐怕会对未来很多Java系统的设计产生相当深远的影响。

昨晚试着把springside里的事务定义改成2.0的模式，发现真的舒爽了不少。不对比不知道啊，Spring 1.0 时的baseTxManager 模式实在太局限AOP的应用了，比如acegi与baseTxManager在定义时的关系。到了2.0才是真正的AOP方式定义AOP.

另外robbin提到的通过AOP，在容器外创建对象时依然进行IOC也是个很重要的特性，我们就可以打破 one bean, one xml define的限制，什么都需要在xml里定义一遍，也是非常非常影响spring应用的。 现在可以把*.*.*Manager.init(..) 批量加入autowirebyName的注入,哈哈。 robbin有这个Aspect的sample code么？

15 楼 liuyifan.com 2006-10-08  

竞然撞贴...

14 楼 liuyifan.com 2006-10-08  

iamjxc 写道

robbin提到：
其实针对Rich Domain Object更进一步，如果将DAO功能作为Domain Object的抽象父类，那么持久化对象PO就会集PO，DAO，Service对象于一身，整个业务层，持久层完全合并为一个对象，通过这种方式进行框架简化得到的结果就是，高度类似于ruby on rails的full-stack的MVC框架。

与我们讨论了很多PO/DAO/Service分层的做法不是背道而驰了吗？

设计是要因时因地制宜的......

13 楼 robbin 2006-10-08  

iamjxc 写道

robbin提到：
其实针对Rich Domain Object更进一步，如果将DAO功能作为Domain Object的抽象父类，那么持久化对象PO就会集PO，DAO，Service对象于一身，整个业务层，持久层完全合并为一个对象，通过这种方式进行框架简化得到的结果就是，高度类似于ruby on rails的full-stack的MVC框架。

与我们讨论了很多PO/DAO/Service分层的做法不是背道而驰了吗？

是的。

12 楼 iamjxc 2006-10-08  

robbin提到：
其实针对Rich Domain Object更进一步，如果将DAO功能作为Domain Object的抽象父类，那么持久化对象PO就会集PO，DAO，Service对象于一身，整个业务层，持久层完全合并为一个对象，通过这种方式进行框架简化得到的结果就是，高度类似于ruby on rails的full-stack的MVC框架。

与我们讨论了很多PO/DAO/Service分层的做法不是背道而驰了吗？

11 楼 stone 2006-10-06  

一个完全依赖于spring的稍大一点的应用，使用xml配置bean和其之间的依赖关系简直就是一场噩梦。
不知道robbin说的脚本配置是怎样的一个配置，可否举一个例子？

10 楼 江南白衣 2006-10-05  

对spring 折腾这么快一年时间,又搞了个很臭美的倒数后，只推出这么点功能不是很满意，对CRUD代码与编程架构影响都不大：）

而它的jira里还有很多我认为不错的功能还没有做出来。

看来真的是东西大了，想改起来就难了。 他应该把更多集成剥离到springmodules式的项目里，保证core可以快速升级。

9 楼 garnoopy 2006-10-04  

一个东西太过于强大了，往往是它衰弱的开始。太复杂了。

8 楼 pedestrian_I 2006-10-04  

集成AspectJ，这个是最大的用处……

7 楼 boogie 2006-10-04  

robbin 写道

将所有的bean之间的依赖关系，组装关系统统使用XML来描述，本身就会导致XML阅读和修改一定的困难。并且用XML配置本身无法直接进行单元测试来验证依赖关系。因此，当bean之间关系越复杂的时候，XML配置文件本身的维护也是一个负担。

我觉得组装关系使用XML来描述很好，不是提供Spring IDE了吗？ 至于用脚本语言那应该是第三方做的事！

6 楼 温柔一刀 2006-10-04  

新特征好象对我的用处不大啊