发现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开源框架里面最优秀的快速开发框架之一了。

评论

20 楼 jarwang 2008-07-07  

  不发解，感觉seam跟 Oracle ADF是不是同一级别的东西？也就是说seam已经不是hibernate框架之类啦，而一种组件级的东西。从持久层到VIEW等层都有涉及。

  有人知道Oracle ADF 与JBoss Seam有什么可比的吗？

19 楼 lonlyleo 2008-07-07  

刚才写了一点，没登陆，白写了。

对JSF和Seam都因为恐惧而没有深入接触

习惯了随心所欲的控制web界面上的各种元素，总觉得用拖拖拽拽的JSF会束缚WebUI的开发。
而以前开发EJB时的不爽的体验，也对JBoss失去了兴趣，最大的痛苦就是deploy；

看来星星还是那颗星星。

要不要跟风学习一下JSF和Seam呢？

18 楼 HenryYu 2008-07-07  

Seam研究过一阵子，感觉是jboss各种技术的糅合体，更多像是一种j2ee企业应用开发模式而不是开发框架。另外，讲究分层、架构、复用和模式与代码量大、开发周期长、架构烦琐等没有直接关系。

17 楼 Anatorian 2008-07-07  

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

同时为了便于开发，seam也注意了其它地方。比如，
1 大量的使用annotation，减少xml，
2 使用 事件机制， 让方法解耦，
3 集成很多方便使用的技术，richfaces, pdf, rule based 权限机制，等

seam瞄准了企业开发，和jbpm无缝集成，加入 business scope就是专门做这事的。

seam和spring很不一样，使用的时候，要有一痛苦的观念转变过程。


另外，关于OpenSessionInView的问题，seam的文档里好像有专门的说明。传统的opensessioninview不能处理这种情况，当view生成完后，关闭session的时候，可能有一部分状态没有能够成功的持久化到数据库，但是由于view已经生成，用户也无法得到持久化不成功的消息。 seam 没有使用传统的OpenSessionInview。它的hibernate session和 conversation及jsf之间存着联系。当conversation开始时，会开始session和一个事务，在jsf的 Invoke Application phase之后提交事务，保证数据的持久化。而之后这个session并不会关闭，她会开启到conversation结束，而conversation是能跨越redirect get 的，所以后面get 生成view时，也不会出先 LazyInitializationException。 hibernate session可以跨越多个请求，比opensessioninview还要长。

16 楼 zergling_zzh 2008-07-07  

支持，看了许多web框架，感觉seam对于web开发的问题域考虑的非常全面。给予一定的时间难保变成像hibernate统一orm那样一统web框架 ：）

15 楼 robbin 2008-07-07  

huixjan 写道

lgx522 写道

自从RoR流行以来，EJB时代所强调的一分二分再分变为了一合二合再合，Java界合下来的结果就是Seam。

每次来JavaEye，不想跟别人较什么劲，但是每次总会发现一些个无知的人在说一些无知的话。不明白lgx522说的所谓什么“自从RoR流行以来”是什么意思，RoR对于业界的影响最大的无非是敏捷开发和默认大于配置的思想而已，如果单纯从技术角度出发，RoR还远没有走在技术的最前沿。

lgx522 写道

Java界合下来的结果就是Seam”，

不知道lgx522了解不了解目前Java EE的现状，Java EE6预计下半年不久就会发布，其中最引人注目的是EJB3.1和JSF2.0以及WebBean，WebBean就是Gavin King提出来的，目前Gavin King跟Bob Lee共同支持和制定WebBean的相关规范，草稿已经发布。seam目前的角色跟Hibernate很相似，JPA规范是Hibernate实现的一个子集，JPA可以使开发者免于底层的ORM实现，所以无论Hibernate,OpenJPA,TopLink都可以使用。seam也是同样的，是WebBean的一个参照实现而已，所以最终的结果不是seam，而是WebBean。

虽然最终的Java EE6会是什么样还不得而知，但可以肯定的是，它的最终目标是使Java开发更加简化，而且更加贴近开源社区。目前的seam2.1已经可以整合wicket,所以将来Java EE6对于目前流行的开源项目会是一个更好的整合点。几天前跟robbin还在帖子上讨论Java与RoR的前景，我选择从RoR回到Java，可以看到Java的进步，更看好目前Java界。

我看你也挺莫名其妙的，lgx522明显是支持Seam和Java EE的，就说了一句RoR如何如何，就踩了你的尾巴了？RoR走的路子和Seam是不一样的，Seam这种强调服务端组件状态的框架完全不适合互联网应用，但它特别适合企业应用，而RoR是反过来的，这两个的应用领域不一样，并不冲突吧？

何况我这个帖子是探讨Seam和Spring2.5的，请你也不要随便跑题吧。 有空就多发表发表你关于Seam和JSF方面的实战经验，谢谢。

14 楼 huixjan 2008-07-07  

lgx522 写道

自从RoR流行以来，EJB时代所强调的一分二分再分变为了一合二合再合，Java界合下来的结果就是Seam。

每次来JavaEye，不想跟别人较什么劲，但是每次总会发现一些个无知的人在说一些无知的话。不明白lgx522说的所谓什么“自从RoR流行以来”是什么意思，RoR对于业界的影响最大的无非是敏捷开发和默认大于配置的思想而已，如果单纯从技术角度出发，RoR还远没有走在技术的最前沿。

lgx522 写道

Java界合下来的结果就是Seam”，

不知道lgx522了解不了解目前Java EE的现状，Java EE6预计下半年不久就会发布，其中最引人注目的是EJB3.1和JSF2.0以及WebBean，WebBean就是Gavin King提出来的，目前Gavin King跟Bob Lee共同支持和制定WebBean的相关规范，草稿已经发布。seam目前的角色跟Hibernate很相似，JPA规范是Hibernate实现的一个子集，JPA可以使开发者免于底层的ORM实现，所以无论Hibernate,OpenJPA,TopLink都可以使用。seam也是同样的，是WebBean的一个参照实现而已，所以最终的结果不是seam，而是WebBean。

虽然最终的Java EE6会是什么样还不得而知，但可以肯定的是，它的最终目标是使Java开发更加简化，而且更加贴近开源社区。目前的seam2.1已经可以整合wicket,所以将来Java EE6对于目前流行的开源项目会是一个更好的整合点。几天前跟robbin还在帖子上讨论Java与RoR的前景，我选择从RoR回到Java，可以看到Java的进步，更看好目前Java界。

13 楼 lgx522 2008-07-07  

自从RoR流行以来，EJB时代所强调的一分二分再分变为了一合二合再合，Java界合下来的结果就是Seam。
这其实是比较务实的，毕竟大多数项目搞那么多层是没有必要的，来来回回绕那么多弯，最后也未必真能复用到哪里去。
MVC已经足够了。这一点上，RoR已然作出了回应，Seam也是大势所趋。

JSF这东西，以Struts这类的习惯性思维来衡量是不行的。它本质上是标准化平台性质（Sun似乎就喜欢搞这种事情），大家可以对其进行扩展改造，以适应自己的需要。所以如myfaces、RichFaces、ICEFaces、AOM这类的东西才大有可为。

坚守Java领域的同道，大可以考虑好好研究应用Seam。虽然初始开发效率还是不如RoR（大概有1/2），但深入下去静态语言的优越性会慢慢体现出来，最终效益如何未为可知，还待大家实践。

12 楼 robbin 2008-07-07  

bottom 写道

看来robbin也很久没有看spring了。要注意的是，每当写到“不象spring那样...贬义词...”时，建议还是去看看spring最新的文档，看该缺点是否还在，要么就注明“不象spring（版本号）那样。。。”。曾经有人不注意这点，结果被spring team耐心地教育了一番。

我很期待被你耐心的教育一番，我很想借这个机会讨论讨论Seam和Spring 2.5，真的。

引用

另外，seam也是用了OpenSessionInView。如果说讨厌的话，两个frameworks都适用。俺用了很久，倒也不觉得有什么问题。

还是有很大不同。Spring的OpenSessionInView并不是一种被Spring官方推荐的模式，在View中延迟加载数据的时候，已经离开了事务的控制范围了，在某些特定的情况下，会造成数据不一致的问题。特别是有远程调用的情况下，更需要手工处理Session，确保远程调用方法结束的时候就立即关闭Session。Seam看起来没有这些问题，当然我现在还不太清楚Seam的底层实现机制。但是官方文档上面这是一个Seam被宣传的亮点，那应该就不会出现Spring那些问题了。

引用

虽然我觉得Gavin King人不怎么样（以前），但对事不对人，俺也觉得seam是不错的东西。要是和spring比的话，因侧重点不同，不好直接比较。

你可以说说看我对spring有哪些贬低的话，我已经看过了一遍spring2.5的文档，确实很想知道现在spring有哪些我还不知道的，特别不一样的东西。

11 楼 bottom 2008-07-07  

看来robbin也很久没有看spring了。要注意的是，每当写到“不象spring那样...贬义词...”时，建议还是去看看spring最新的文档，看该缺点是否还在，要么就注明“不象spring（版本号）那样。。。”。曾经有人不注意这点，结果被spring team耐心地教育了一番。

另外，seam也是用了OpenSessionInView。如果说讨厌的话，两个frameworks都适用。俺用了很久，倒也不觉得有什么问题。

虽然我觉得Gavin King人不怎么样（以前），但对事不对人，俺也觉得seam是不错的东西。要是和spring比的话，因侧重点不同，不好直接比较。

10 楼 fangshun 2008-07-07  

robbin 写道

以上是我对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开源框架里面最优秀的快速开发框架之一了。

1.这几天为项目加入了facelets模板机制，可以很好的解决密密麻麻tag的问题，facelets的行为解决了jsf渲染层面的不足。
2.打包ear只是jboss一厢情愿的做法，完全没有必要这样，我现在的做法，Tomcat底下跑facelets+seam+myfaces+spring+hibernate,利用seam的集成测试，可以把单元测试提前到表现层来测试了，测试的范围更加扩大，而且seam最酷的地方就是和spring良好的集成，spring里面可以直接注入seam组件或者作为seam组件存在！

9 楼 Anatorian 2008-07-07  

虽然已经用seam 做过一个应用了，但是还是觉得seam不够好，不满主要来自于JSF。不过做做简单的以表单堆起来的应用还可以，其它应用的话，用起来还是很麻烦。期待seam什么时候与 jsf解耦。

8 楼 家常咖啡 2008-07-07  

Seam实际上是对JSF架构的延伸和扩展，可以说Seam和JSF是息息相关的。JSF本身就是一个完整的Web架构，超出JSP或Servlet等技术的范畴，文中所说到的组件和数据绑定等特性都是JSF的特性。
JSF的界面开发更多要借助工具来进行。目前，Java集成开发环境，如NetBeans，对JSF的支持已经做到所见即所得，对组件拖拖拽拽进行布局，然后对组件的属性进行设定，类似开发桌面GUI应用的方式。
当然，直接让美工采用Java集成开发环境来工作还是不太现实。JSF已经将Web界面完全从处理中提取出来，这实际上提供了一种可能，即让现有Web界面设计工具（如FrontPage或dreamweaver等）来生成JSF页面。如果能有人开发出这样的插件或工具（将HTML转换成JSF标签），相信将会将JSF应用提到更高的层次。

7 楼 isky 2008-07-07  

<p>seam 没有几家公司用吧</p>

6 楼 koda 2008-07-07  

什么脚穿什么鞋，对于企业应用，Java仍然是我的首选，但是对于很多Internet项目，至少在启动期，我仍然会选择脚本语言，至于静态语言，尤其是java有什么问题，Robbin已经说了，我再强调一下：
1. 蹩脚的tag式页面--仅仅是看上去很美。
2. 随便改个东西就要重新打包发布--太不Agile了吧

为了应付复杂的应用，没有任何语言的平台可以宣称自己足够简单。这是个哲学问题。如果为了一个简单的应用选择SEAM，学习成本是必须考量的，至少，你的团队的人都必须是专业的人，你的团队，准备好了吗？

5 楼 cats_tiger 2008-07-06  

robbin看到的两个不足也是我不用seam的原因，本来就不喜欢JSF，再怎么整合也是废柴。期待JSF2.1吧。
Jboss重复的启动也非常不爽，不如jetty快，没想到每次修改还需要打包和deploy，让我想起了N年前用EJB的痛苦经历。个人觉得所谓“快速开发框架”，container的启动速度是非常重要的一个特性，既然java不能做到自动的ClassLoad，那么就让Container尽量快的启动。seam在这个方面做的还不够。

4 楼 may_cauc 2008-07-06  

facelets + seam + jpa(hibernate) + tomcat

利用jboss tools 作为开发环境，相当方便，不用ejb的话能解决楼主的全部的问题

3 楼 Anatorian 2008-07-06  

可以以explode的方式发布的。这样*.xhtml和*.page.xml都不需要重部署就可以生效了。令外，放在war/WEB-INF/dev/下的classes能够热部署，但是有些限制：
1， 不能是EJB，只能是POJO
2， 不能被在war/WEB-INF/dev/外的类引用 
3， 不能是实体类

我们刚用seam 开发过项目，走过不少弯路呀。正在摸索一个seam的最佳实践

2 楼 melin 2008-07-06  

打成ear也要吓退不少人，真实因为这个原因，所以就没有尝试过seam。j2ee的顽症。EJB 3.1如果能直接发布成war包，直接部署在servlet容器中就好了。我现在用openEJB就这样的。弄一个jetty。

1 楼 happylo 2008-07-06  

基于JSP的JSF页面看上去确实头皮发麻，一般来说，基于SEAM的项目会推荐使用Facelets，它是使用JSF的一种全新方式，使用起来非常舒服。