Seam框架学习之一(Seam vs Spring -- state vs stateless)

Seam是JBoss 的新的框架,号称Java的ROR.下面我想对它的一些特性和Spring做一番比较.

        Seam的概念是基于Component的,集成了JSF+EJB3.0以及它选用的AJAX框架Ajax4JSF,还有它的工作流jBMP等等.使用了新的XHTML技术,页面上都是标签,被JSF封的死死的,就连Ajax也是以标签的形式出现,这不得不说是一场革命性的变革.以后的程序员可能再也不用写request.getParameter之类的东西了,程序员将不必再关注底层的代码,更关心的是流程,webflow,workflow流程的定义.

        现在我们来回忆一下Spring1.x怎么开发J2EE应用的(虽然Spring2.x加入了bean对象生命周期的管理)...Spring配置的单态bean有两种方式:单态和原型.都是无状态的bean,我觉得这样的设计在没有什么太多的业务逻辑的时候完全没有问题,简单的CRUD操作不涉及太多的状态,但是对于一个有着复杂的业务流程的系统,这样做是有问题的,如网上订单购物系统,中间状态如何保存?对于原来的J2EE应用,如果不用EJB,我们可以有两种解决方法,一种是保存在session里,另一种是保存在数据库里.前一种的问题是:用户操作的时候,有很多事情要做,一个session里放入过多的不同业务的属性,状态是很混乱的,而且随着用户操作,session将越来越大.这是不合理的.第二种方式:存到数据库里,如果并发很大的情况,那么频繁的访问数据库是灾难性的,每个状态都要保存到数据库里,不可想象.所以说Spring1.x设计是很有问题的.就算Spring2.0有了状态的管理,也是基于session级别的bean,我觉得没什么用.:-)那么Seam是怎么做的?我下面将阐述Seam的解决方案...

       Seam框架里用到一个context的概念,和我们所说的scope对应.除了request(seam里叫event),page,session,application以外,还加入了新的context,conversation context和business process context这两种,大家一看就明白了,基于会话和业务逻辑的生命周期在解决上述问题的时候是更加合理的.只要你的应用有业务的流程,这样是很正确的.会话上下文的范围是在request和session之间,业务逻辑上下文是jBMP工作流引擎来管理的,Seam更偏重对象生命周期的管理,JSF和entity bean绑定,通过session bean的listener控制输出.我相信Seam会更有前途,当然这里没有说不应该用Spring.

       综上所述,个人感觉,如果J2EE应用没有过多的业务逻辑和状态的设计,用Spring是很好很好的解决方式,对数据的保存,无状态的业务bean的使用是一点问也没有的.所以在选择框架的时候,需要大家考虑清楚:-)

       以后我将陆续推出seam框架的使用方法介绍的文章,各种技术同Spring 的对比,如AOP,RichClient,webflow等,以及对持久层的支持,hibernate3,EJB3.0的支持,对JPA标准的支持,对annotation的支持等等...

       以上文字全都是原创的,仅仅代表个人观点.