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

评论

40 楼 fangshun 2008-07-07  

打倒小日本 写道

我跟大家的情况都不太一样
我正式因为JSF才背叛Spring 开始使用Seam的
Seam的理念也只有跟JSF等有状态VIEW层框架才能发挥出威力

我也是使用jsf才引入了seam的支持！
seam从设计上兼容spring，提供更高层次的组件化。
即使我使用的是seam+spring整合，也能不断的感受到整个框架体系的业务管理重心正在不断朝seam转移！

39 楼 JeffreyHsu 2008-07-07  

seam很强大，很容易开发，但是并不意味着就容易学习。

38 楼 打倒小日本 2008-07-07  

我跟大家的情况都不太一样
我正式因为JSF才背叛Spring 开始使用Seam的
Seam的理念也只有跟JSF等有状态VIEW层框架才能发挥出威力

37 楼 fangshun 2008-07-07  

推荐JBossTools 2.1.2，可以很好运行在eclipse3.3下面，对seam的元注释提供了很好的IDE支持！

36 楼 JeffreyHsu 2008-07-07  

哇咔咔，robbin终于也向seam妥协了

现在正用seam做一个自己的web项目，预计年底发布开始上线运营，到时候把源码贡献出来，吼吼

35 楼 lgx522 2008-07-07  

xiao0556 写道

Spring 用的不多，倒是用Seam做了一年多开发。给我的感觉就是 我越来越恨seam了 不！应该是说恨jsf 。seam还是不错的 怎么就跟jsf弄一起了 还粘合的这么紧 直接被带坏了。当然如果你的应用没什么复杂交互的话 你真是很幸运

很早以前大家争论JSF的时候，本人当时的观点是“能用”，现在依然如此。
JSF很大程度上是以ASP.NET为参照的，所谓的“事件驱动”很多时候也就是靠“binding”。简单页面固然方便，复杂交互就必然是不如“请求驱动”的framework了。
ASP.NET做到如此的程度，做得深入的还不是越来越恨binding，何况是JSF这种半成品。毕竟凡事有利有弊，要有完美的早就一统天下了。

复杂交互的话，都不容易，“事件驱动”的不如“请求驱动”的，有framework不如无framework。但不要忘记，90%都是简单问题，所以说JSF“能用”。

34 楼 robbin 2008-07-07  

phoenixup 写道

2.Seam有两种模式，开发和产品模式，在开发模式中，你用的是exploded不是deploy。

多谢提醒，看了一下exploded这个task，终于搞明白了，他就是把project下面的文件给拷贝到JBoss的deploy下面去。因此如果没有更新特定的部署描述文件的话，JBoss就不会reload app。

总得来说，看来大家对于Seam的问题主要还是集中在JSF的限制上面。

33 楼 5day 2008-07-07  

就是为了seam，我才搞了个双核的CPU和2G内存。

不过如果有点E文基础，想用seam作个东西真的比以前简单很多。
最喜欢的是richfaces里面的东西和双射。
可惜的是我java功底太薄，不得精髓。
对怎么结束conversation仍然没有很好的办法。

32 楼 jarwang 2008-07-07  

Joo 写道

jarwang 写道

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

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

这边好像很少有人提及Oracle ADF,去年年底的时候心血来潮摆弄过一阵,感觉速度比Netbeans快,开发更人性化,就是不太明白里面几个打包部署的概念,最终不了了之.不过觉得他们的UI还是蛮漂亮的

有谁能详细比较一下吗？ORACLE ADF还是不错的，开发效率很高，再说ORACLE10G的那个web enterprise management好象也是这用ADF写的。另外EBS12R也用过ADF写部份。


有谁能详细比较一下吗？

31 楼 phoenixup 2008-07-07  

cats_tiger 写道

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

有问题，可以看看解答~~robbin的两个问题，根本不是问题~~不过你说的JBoss启动速度的问题。。我没什么好的办法。。。弄个4G的内存，4核的CPU吧，开发测试就爽了。

30 楼 phoenixup 2008-07-07  

melin 写道

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

Seam setup中有是EAR和WAR包的选择，另外内置的EJB容器JBOSS已经提供了，在Tomcat或Jetty中使用EJB，现在不存在问题啊，配置一下，只是lib包的增减罢了。

29 楼 phoenixup 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.Seam 2的版本中默认的视图展现是Facelets的xhtml，配合jsfc标签，完全不存在robbin你说的问题，不过jsp遗留的tag确实是不能避免，但是有了Faceltes这个貌似不是问题了。

2.Seam有两种模式，开发和产品模式，在开发模式中，你用的是exploded不是deploy。

28 楼 Joo 2008-07-07  

jarwang 写道

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

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

这边好像很少有人提及Oracle ADF,去年年底的时候心血来潮摆弄过一阵,感觉速度比Netbeans快,开发更人性化,就是不太明白里面几个打包部署的概念,最终不了了之.不过觉得他们的UI还是蛮漂亮的

27 楼 DigitalSonic 2008-07-07  

我没用seam做过实际的项目，所以说不上喜欢或者讨厌，对它的了解完全出自seam reference，翻译它的时候就看着demo里那一堆堆的jsf tag犯晕。。。不是很喜欢在页面里大量使用tag。

起先在和朋友讨论seam时我们都怀疑seam里这么多的状态做起集群来会不会很麻烦，毕竟这些不同机器上的组件的状态都是要同步的。但后来在看reference中关于cache的部分是发现seam对于集群的情况已做了充分的考虑，起码实现起来没有之前想的这么复杂。

如果还要说有别的印象的话，那应该就是它对jboss的东东整合的很好，其他也就不记得什么了。。。

26 楼 wjason 2008-07-07  

关注ing

25 楼 Anatorian 2008-07-07  

xiao0556 写道

Spring 用的不多，倒是用Seam做了一年多开发。给我的感觉就是 我越来越恨seam了 不！应该是说恨jsf 。seam还是不错的 怎么就跟jsf弄一起了 还粘合的这么紧 直接被带坏了。当然如果你的应用没什么复杂交互的话 你真是很幸运

同感，同感。

24 楼 xiao0556 2008-07-07  

Spring 用的不多，倒是用Seam做了一年多开发。给我的感觉就是 我越来越恨seam了 不！应该是说恨jsf 。seam还是不错的 怎么就跟jsf弄一起了 还粘合的这么紧 直接被带坏了。当然如果你的应用没什么复杂交互的话 你真是很幸运

23 楼 EricLiang 2008-07-07  

jarwang 写道

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

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

绝对不是，Oracle ADF只是JSF的一种，而且用起来问题很多（也有可能是我不会用），ADF本身还有一个持久层的东西，Oracle自己封装的，封装后感觉就像JDBC的ResultSet一样进行操作，根本没有持久化，Seam的话，正如各位所说的，Gavin King也力推的，真的框架，结合JPA，我们则可以关注真正要关注的东西——业务逻辑，而不是框架呀、脚本呀、整合呀等等，我们JAVA社区应该学一学ROR的优点。

22 楼 Anatorian 2008-07-07  

nihongye 写道

seam的view层是一个弱点。
seam的conver...范围，是对jsf的状态保存的拟补。
searm的优点在于整合，降低java web开发的学习成本。

如果只是做一堆表单的话，seam的view层也够用了。貌似这也只是SEAM的目标。

21 楼 nihongye 2008-07-07  

seam的view层是一个弱点。
seam的conver...范围，是对jsf的状态保存的拟补。
searm的优点在于整合，降低java web开发的学习成本。