发现JBoss Seam很棒呀！有用Seam做过项目的吗？

上周去见了一个朋友Mark，他应邀在Red Hat的研讨会上面介绍他曾经用JBoss Seam做过的一个大的项目。因为听了他的演讲，对JBoss Seam多了一点认识，有点出乎意料的方便。所以周末在家下载了JBoss Seam摆弄了一下，把Seam自带的examples都浏览了一遍，也大致看了一下Seam的Reference，感觉挺惊艳的。于是又在JavaEye上面搜索了一下Seam，这才发现自从去年下半年开始，JavaEye已经有大量关于Seam的讨论了，这都一年多过去了，看来自己对Java社区已经有点孤陋寡闻了。

写这个文章的目的是和大家一起交流一下JBoss Seam，虽然我通过文档和代码，已经对Seam有了不少了解，但是毕竟没有用Seam写过项目，希望有这方面经验的朋友多谈谈自己的体会。那么作为抛砖引玉，结合与Spring的对比，我先谈谈自己的感觉吧：


一、Seam适应快速开发、简化框架的趋势

在RoR流行之前，Java社区的主流还是非常讲究分层、架构、复用和模式，而比较忽视快速开发和简化架构的，其结果就是代码量大、开发周期长、架构相当烦琐。以比较常见的Struts/Spring/Hibernate为例，从大的分层来说就有Web层、业务层和持久层，从细的分层就从前到后有：View(JSP) -> Struts Action -> Spring Business Object Bean -> Spring DAO Bean -> Hibernate Persistent Object。如果有Remoting调用，那么还需要相应的Service Facade层。每层都是用不同的技术框架或者模式、各层之间整合的方式也是五花八门。把整个项目的架构搭建起来，已经是非常麻烦的事情了。

Seam给我的感觉像是一个异常简单的MVC框架，他实际上只有两层：JSF View和 Seam Component。而Seam Component有两类：一类是Entity Bean，另一类就是Session Bean。Entity Bean映射数据库表，Session Bean完成所有的业务逻辑，包括可能的持久化，事务，响应页面请求、商业逻辑，页面流控制等等。配置文件也不多，除了一堆基础的配置文件，唯一一个需要不断修改的就是pages.xml了，即配置JSF的view映射。

所以Seam开发项目看起来很简单、很直接，无分层之苦恼。相应的也会让程序员把精力主要放在业务逻辑组件的实现上，而不是把精力浪费在架构、分层、模式和基础设施搭建的工作上面。


二、Seam的数据绑定做的很出色

由于是一个简单的两层结构，View和Component之间的数据绑定做的很出色，看起来比我欣赏的Webwork的数据绑定方式更胜一筹。官方的说法叫做双向依赖注入，在component里面可以直接取到页面提交的数据，在页面也可以直接访问component数据。

另外持久化数据的校验也直接集成好了，在EntityBean里面声明数据的约束，在页面就可以直接校验了，和RoR的数据校验方式是一样的，当然这也得益于Gavin King是Seam和Hibernate两个项目的作者的缘故。


三、Seam的组件机制看起来相当好用

既然Seam简化了分层，实际上把主要的工作都推到组件层去完成了。但是Seam的组件层看起来很简单，这得益于Seam的组件机制设计了很多的组件状态，根据不同的组件状态，天然的划分了不同组件的功能和逻辑。

Seam的组件有点类似于把传统MVC的Action和Spring的Bean合二为一了，但还是不同于传统的MVC框架下面的Action：传统的MVC Action是基于页面请求的，无法复用，而Seam的组件是事件驱动方式，它只需要捕获和实现事件代码就可以了，至于怎么触发它并不需要知道，他和Web层可以不绑定，因此理论上面来说是可以实现组件复用的。我个人认为Seam的这个组件机制非常巧妙，既可以用来实现响应页面事件，绑定页面数据的所谓Web Bean，也可以用来实现和Web没有任何关系的纯业务逻辑组件，一个很漂亮的实现。

另外Seam的组件注入机制看起来也很简单，不像Spring那样麻烦，而且内置了很多现成的组件进来，直接用Annotation声明一下就可以用了，感觉写组件真的很方便、很灵活、很强大。


四、Seam把数据库资源的管理和事务的封装完全隐藏起来了

Spring的数据库资源管理和事务封装是通过提供了一系列的代理类以及配置文件来实现的，程序员还是要通过配置文件的方式来手工管理事务，访问数据库也必须通过Template编写匿名内部类来实现，而且在Spring/Hibernate框架下面，OpenSessionInView是一个很讨厌的问题。

但是Seam已经把数据库资源的管理和事务的封装全部都隐藏起来了，程序员完全不需要知道，也不需要操心这些事情，这真是个大大的解放。当然Seam可以做到这一点，也无非是因为Seam提供了一套上至View层，下至持久层完整的框架，因此可以把实现细节隐藏在框架内部，不暴露给程序员。Spring之所以做不到这一点，也因为他只充当了一个黏合剂，不能够直接修改View层和持久层带来的限制。


五、Seam对第三方框架的整合看起来比Spring更深入

原来印象当中只有Spring才提供了一站式的解决方案，这次一看Seam文档，呵！发现Seam也都齐全了，什么邮件啦、工作流啦、页面流啦、规则引擎啦、异步任务调度啦、消息系统啦、Web服务啦、远程调用啦、甚至全文检索啦全部都集成了。而且集成的比Spring更深入一些，例如Java EE本身的JMS，MDB自然是Seam的强项，而JBoss自家的JBPM，JPDL，Rules集成的更加没得说。

从整合角度来说，感觉Spring和Seam的出发点不同：Spring更像一个平台，我提供整合的可能性，然后程序员你自家去整合，我提供一些写好的整合bean，对于这些你通过XML配置一下就整合进来了，如果我没有提供bean的，那么你也可以自己写bean来整合。而Seam更像一个完整的框架而不是平台，我这个框架想提供的功能，框架自身就已经整合好了，你直接用就是了，你也可以自己写扩展来整合，但是这个不是Seam希望程序员做的事情。

因此对于程序员的感觉来说，Spring给你提供了一切的零件和半成品，但你要自己动手来组装，而Seam已经给你装好了一个成品，你就别自己改装了，直接拿去用吧。


六、Seam提供了方便的代码生成器

和appfuse类似，可以直接用ant task来生成一个完整项目的骨架，以及相应的组件代码生成器，利用seam-gen可以快速生成一个完整的、带有AJAX功能的CRUD项目，而且还是一个eclipse或者netbeans工程，你可以直接用IDE打开编辑了。这功能虽然不太难做，但是对于程序员来说，帮助是很大的。Seam做的相当不错。


以上是我对Seam的一点小小的赞许，当然我也有一点疑问：

一、Seam的View实现是JSF，看页面代码还是密密麻麻的Tag

我是非常反感JSP Tag的，看看页面密密麻麻的Tag就头皮发麻，能不能弄一个Template呀，例如freemarker啥的？这些Tag既不直观，也不方便扩展。需要扩展页面组件，总不能让我自定义Tag去干活吧？不清楚这个问题怎么办？像freeamarker还可以方便的自定义页面宏呢。

二、每次修改都要重新打包发布，太麻烦了吧

就算修改一个页面，也要整个打包deploy成为一个ear去拷贝到jboss的应用目录下面，这个要是改页面，不是得烦死？ 我以前都是在项目里面直接内嵌Jetty，作为一个application启动，修改页面根本无需重起呀，更不要说deploy了。


总体来说，我觉得Seam框架非常出色，尤其是他的组件机制设计的很有匠心，真不愧是Gavin King精心打造的框架了，虽然看起来还是有些缺陷，但是做企业应用项目的话，Seam是一个很棒的选择，作为程序员来说，要比用Spring/Hibernate/Struts省心的多，更能够把精力放在业务逻辑的编写上面，开发效率也很不错，可能是Java开源框架里面最优秀的快速开发框架之一了。

评论

140 楼 upheart 2008-09-16  

Anatorian 写道

seam和spring最大的区别，就是seam的组件可以是有状态的（或者说状态丰富的），而spring的bean则是无状态的。spring的bean并不记得上一次调用它的时候，它具有什么状态。但是在seam中，一个组件在它生存期内，是可以有状态的。Gavin认为人们在开发spring+ hibernate时遇到的阻力主要是来自于hibernate是有状态的，页面表现层也是有状态，但是spring却是无状态的。是这种有状态与无状态之间的不对口，导致orm的能力不能全部发挥，导致了从表现层到服务层的时候状态转换的麻烦。所以seam的理念，就是stateful。

我也觉得这是seam最大的亮点，也是seam大肆宣传的地方，也就是他的有状态，尤其是conversation状态，这个才是seam开发速度大大提升的诀窍，这个功能也是WebBean规范的主要内容之一。

spring对此也不是无动于衷，马上出来了spring web flow2.0，如果仔细看一下它的flowscope和coversation scope和seam的stateful是如出一辙的，和JSF的整合也很好。当然和ORM的整合就没有seam那么全面了，总之，大家在竞争中互相学习这是很好的事。有人甚至说spring web flow这次是抄袭了seam，希望seam学习一下spring容易在轻型容器（比如tomcat）中容易部署的特性。

感兴趣的可以看看TSS上的讨论：http://www.theserverside.com/news/thread.tss?thread_id=49421

挺spring的人说spring  web flow的方式比seam更加的WebBean。

当然spring web flow2.0 刚刚发布不久，很多地方不如seam那么成熟，不过我很看好，拭目以待吧。

139 楼 yunjitang 2008-08-31  

Seam真是不错。gavin king真是一牛人。我觉得JAVA还是一片春天呀。SPRING在怎么叫。框架在怎么多。SUN公司的标准目前还是企业级应用首选！

138 楼 iamlibo 2008-08-28  

JSF\Struts等这些框架主要是看用在做什么样的项目上.各有优缺点.因为他们的机制不一样.Struts是页面驱动的,JSF是事件驱动的.如果你JSF开发一个以页面为主的新闻网站(不太确切)当然觉得不合适了.JSF+AJAX才是解决复杂的业务逻辑的WEB框架.

137 楼 nimrob 2008-08-24  

也不说用过jsf有多深入，给我的感觉还是作的太复杂，有点因为技术而技术的感觉。这么多年也没起来。

136 楼 qdzheng 2008-08-21  

看了主帖感觉是基于JSF的，或者说是JSF的一种实现，
回帖中也有这样的观点，估计跟myFaces一样吧。

本来以为JSF是好东西，用起来感觉还是太笨拙了。

135 楼 mmylover 2008-08-21  

拿seam做了几个月的项目了，一个字，乱。。。。。 而且效率问题 实在不敢恭维。不知道能经的住多少并发。曾经测试过，并发多几个的时候，就会返回空白，什么也没有。用的是seam2.0

134 楼 zjtyxy 2008-08-21  

因为jboss支持文件夹方式部署，可以建立一个目录，里面放入ear的文件夹，然后在jboss的config里吧路径指向这里，这样jsp文件，或者一些类文件函数里面的修改，就不需要重新启动jboss。也不用打包什么的

133 楼 tonik 2008-08-19  

第2个问题
虽然框架交jboss seam 没有必要非得用jboss吧
别的也可以，和seam本身没有关系

132 楼 tonik 2008-08-19  

1.seam是可以不用jsf的，那么多表示层，你随便选啊
任何一个框架，没有说从前台到后天都必须用他自己的

2.这个是你开发模式的关系吧，我不是很了解啊 乱说一下
我修改ejb只要重新发布ejb，就ok了，都不用打包，修改web也只重新发布web
jboss好像也可以支持散包部署的吧？
开发的时候，最好不要打成ear包，jar和war分开

我没有用过seam 但是，也听说过myseam
你对seam感兴趣，那就也关注一下myseam，估计会同样让你兴奋，到时候研究了，再发表一些文章里来让大家学习学习嘛

131 楼 andyhan 2008-08-04  

非常看好Seam的未来：

What's New in Seam 2.1 - An interview with Peter Muir
http://java.dzone.com/articles/whats-new-seam-21-an-interview

130 楼 afadgaeg 2008-07-26  

看了TAPESTRY的hello world,还有一篇比较jsf和TAPESTRY的文章好象写得非常透彻
http://chxkyy.iteye.com/blog/183346
TAPESTRY和jsf+facelets差不多啊，可能两种框架以后可能越来越像
wicket也是事件驱动，大同小异吧
学好一种就够了
richfaces等扩展对身兼程序员和美工的人来说还是很方便的

满江红seam翻译我找到了，感谢这位仁兄
不过最近可能没时间看
多学些框架（我想最好是看源码），了解他们的设计思路，总有好处啊

129 楼 starfeng 2008-07-25  

我单讲JSF和MVC, 都用过, 分析过, 底层重构过.
.Net的人其实能讲出更多事件驱动的缺点,要了解Web的事件驱动,多和.Net人员聊聊会收获更多.

列表前先摆本次回贴观点: 贬JSF
1. 有些在MVC在看起来很方便的功能,基于事件驱动处理会很麻烦: 比方, 集中控制, 页面元素动态生成, 页面随意切换(比方, 直接带参调用一查询页面:xxx/search?name=xxx), 这些我只时即兴想了一下,事实上还有更多. 这些在MVC上是很易做到的, 在JSF或.Net中,很不好实现.
2. 有状态,无状态这东西, 当年EJB上争论了这么久, 换成View层, 又要争半天? 有无状态有各自适用范围, 基本上无状态情况更多. 如果强调一定要有状态...找麻烦.
3. UI展现, 从BS以分层优势击败CS起, 分的思想被滥用. 还好在05年后又逐步回归现性. 但回归不是说不分了,该分的还是要分, 应为分工(比方,开发,美工,Testing)而分,而非为技术(比方重用,维护等)而分,技术上的东西还能用其它技术手段解决 -- 个人看法而已. 那么在这一点上, JSF在很多项目中是不适用的, 特别是稍大一点的项目 -- 他在让程序员和美工都做相同的事.
4. 美学, 简单会带给人享受. 看JSF规范就觉得头大, 一个本来很简单的东西有必要弄得那么长吗? 看来看去就是一个EJB的Web版. 一个不太恰当的比喻是,我只想做块滑版, 也非得按做火箭的设计流程. 其后果是, 性能,跟踪,二次开发 全都不方便.

128 楼 andyhan 2008-07-25  

afadgaeg 写道

TAPESTRY 和 wicket是否贯穿C层？ 好象是个表示层的类似模板技术吧 需要结合struts之类的mvc框架才能用吧 无知之处还请原谅和指出。
hibernate和jsf的构想都是不错的，实现都还难免有不近人意的地方
jsf不是新技术,它借鉴的是桌面系统的思想，类似asp.net的web应用。
它不是一个单纯的一相情愿的想法，是已经在其它系统中成熟实现了的设计构架。
hibernate做得很好，可是对数据访问的高性能要求以及关系数据系统和oop的巨大分歧使它有时候看起来很别扭。
seam把框架和分层弄到了一起，我认为并不是提倡简化分层，而是提供设计的灵活度和配置的简化，把分层的权利交给你自己。
我期待jsf2。0出来后，能够提供注解功能，以及简化导航，aom的思想似乎可以借鉴（我总害怕国产的软件bug太多，aom过分宣传让我心里对它无底）。
jsf和seam应该是一对好的排挡。
我现在在用spring我觉得它设计得很好
其实，好的东西都有些殊途同归的，有空想学学seam。
ejb3的庞大让我这种没机会设计大型应用的人有点不太敢用的感觉。
最郁闷的是 jboss的文档都是e文，包括seam，让我这种英语二流的感到郁闷，啃完文档花大量的时间不说，有的地方还不明不白

Seam 2.0 有中文翻译的文档，满江红的开源文档项目，虽然和最新版本略有出入，对于E文不是很好的同志也算是不错了。其实我倒并不觉得E文文档是障碍，相反的Seam看起来就是一个大杂烩，n多技术都可以与之无缝融合，这些“周边”的东东（主要的诸如JSF，Drools，jBPM等）如果事先没有深入研究就很难一下子上手。

127 楼 afadgaeg 2008-07-25  

TAPESTRY 和 wicket是否贯穿C层？ 好象是个表示层的类似模板技术吧 需要结合struts之类的mvc框架才能用吧 无知之处还请原谅和指出。
hibernate和jsf的构想都是不错的，实现都还难免有不近人意的地方
jsf不是新技术,它借鉴的是桌面系统的思想，类似asp.net的web应用。
它不是一个单纯的一相情愿的想法，是已经在其它系统中成熟实现了的设计构架。
hibernate做得很好，可是对数据访问的高性能要求以及关系数据系统和oop的巨大分歧使它有时候看起来很别扭。
seam把框架和分层弄到了一起，我认为并不是提倡简化分层，而是提供设计的灵活度和配置的简化，把分层的权利交给你自己。
我期待jsf2。0出来后，能够提供注解功能，以及简化导航，aom的思想似乎可以借鉴（我总害怕国产的软件bug太多，aom过分宣传让我心里对它无底）。
jsf和seam应该是一对好的排挡。
我现在在用spring我觉得它设计得很好
其实，好的东西都有些殊途同归的，有空想学学seam。
ejb3的庞大让我这种没机会设计大型应用的人有点不太敢用的感觉。
最郁闷的是 jboss的文档都是e文，包括seam，让我这种英语二流的感到郁闷，啃完文档花大量的时间不说，有的地方还不明不白

126 楼 andyhan 2008-07-24  

期望2.1可以尽快发布，增加了对wicket和RESTEasy的支持，并且增强了权限管理。

125 楼 dengyin2000 2008-07-24  

Seam最终是会解偶JSF的， 好像现在已经有对wicket的支持了。 但是就目前来说用seam的话， 用JSF还是最好的选择。

124 楼 andyhan 2008-07-24  

是不是大家都逐渐跑题了？本帖说的可是Seam框架而不是JSF。

事实上如果仔细研究了Seam 2.x的文档和相关的例子就会发现Seam并不是和JSF绑定在一起的。

123 楼 dengyin2000 2008-07-24  

afadgaeg 写道

我是一个新手，对于所有的框架都不抱有特殊的偏见，为了选型，先后看过大量的资料，学习过很多的框架。
我本人相当推jsf，我想说说我对jsf的理解：
如果把表示、业务、持久之类的分层比做纵向划分，那么jsf不仅实现了纵向划分，也实现了横向划分（关注点分离是不？），类似于aop，或者说组件技术也是如此。这使得编程更灵活和有序。相比以struts为代表的那类框价对横向划分的实现不多，所以西方对jsf极为看重。
jsf现在的实现我感觉相当毛糙。xml配置太罗嗦我最恨
facelets意图摆拖jsp，我觉得很好，至于tag，如果一个有一点xml背景不通jsp的新手先学了facelets之后，回过去学jsp他也觉得不爽的，人之常情。
计算机技术是一层层依赖的，比如http的无状态,sql的非oo(面向过程怎么说来着？)。
对此在后面的技术上人为的“遮掩”还是“拥抱”（来自ibatis极其支持者的说法，很形象，不论褒贬，我先用着），都显得很别扭。
我不得不承认hibernate门派（姑且这么说）和jsf门派的思想比ibatis派和struts派更符合oop和aop(我把aop引申了，不知大家有没有异议)
但是我喜欢ibatis和jsf
ibatis够简单,jsf很直接

组件式的框架 你可以看看TAPESTRY 或者 wicket  都会比jsf好得多

122 楼 afadgaeg 2008-07-24  

seam我不了解，不过看大家说的我心痒痒的，一堆框架整一起烦，不知seam和jboss绑得死不死？

121 楼 afadgaeg 2008-07-24  

我是一个新手，对于所有的框架都不抱有特殊的偏见，为了选型，先后看过大量的资料，学习过很多的框架。
我本人相当推jsf，我想说说我对jsf的理解：
如果把表示、业务、持久之类的分层比做纵向划分，那么jsf不仅实现了纵向划分，也实现了横向划分（关注点分离是不？），类似于aop，或者说组件技术也是如此。这使得编程更灵活和有序。相比以struts为代表的那类框价对横向划分的实现不多，所以西方对jsf极为看重。
jsf现在的实现我感觉相当毛糙。xml配置太罗嗦我最恨
facelets意图摆拖jsp，我觉得很好，至于tag，如果一个有一点xml背景不通jsp的新手先学了facelets之后，回过去学jsp他也觉得不爽的，人之常情。
计算机技术是一层层依赖的，比如http的无状态,sql的非oo(面向过程怎么说来着？)。
对此在后面的技术上人为的“遮掩”还是“拥抱”（来自ibatis极其支持者的说法，很形象，不论褒贬，我先用着），都显得很别扭。
我不得不承认hibernate门派（姑且这么说）和jsf门派的思想比ibatis派和struts派更符合oop和aop(我把aop引申了，不知大家有没有异议)
但是我喜欢ibatis和jsf
ibatis够简单,jsf很直接