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

评论

160 楼 slaser 2009-04-26  

bao110908 写道

公司用 Seam 的，没感觉有多少慢。再说了 Seam 的组件的也不定得是 Session Bean，也可以是普通的 Java Bean。

由于 Seam 框架的特性所决定页面只能采用 JSF 的形式。但是 JSF 本身有很多的缺点，比如有 20 个一组的单选按钮，Sun 的 JSF RI 要么这 20 个全部堆在一行上，要么一行只能显示一个，如果想要一行显示 5 个显示 4 行的话，感觉就不是那么方便了。

说道心里去了，JSF对自由度的牺牲太大了。

159 楼 bao110908 2009-04-21  

公司用 Seam 的，没感觉有多少慢。再说了 Seam 的组件的也不定得是 Session Bean，也可以是普通的 Java Bean。

由于 Seam 框架的特性所决定页面只能采用 JSF 的形式。但是 JSF 本身有很多的缺点，比如有 20 个一组的单选按钮，Sun 的 JSF RI 要么这 20 个全部堆在一行上，要么一行只能显示一个，如果想要一行显示 5 个显示 4 行的话，感觉就不是那么方便了。

158 楼 sxlkk 2009-04-20  

juzhibest 写道

phoenixup 写道

cats_tiger 写道

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

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

我也是遇到这个问题.
我这1G+2核  开机之后只能运行 seam+jboss+eclipse  再加一个浏览器了.

内存已经寥寥了.

公司用seam做开发，借此申请了一个1G内存，现在双核+2G运行seam程序有些慢啊，这个应该不是编程的效率问题了，应该是seam框架本身的问题，那么一大堆文件要加载，不慢才怪呢，有哪位仁兄能运行着seam程序比单纯的jsf+ejb的速度快一定要告诉一声，小弟先谢过了

157 楼 slaser 2009-04-10  

zjsun 写道

疑惑一：JSF其实也仅仅是个规范而已，Tag自然有Tag的道理，从长远来看，以后的client不一定只是浏览器（能够识别html），如手机设备等，JSF的好处即是：如果你采用了JSF规范实现的tag，可以替换相应的render-kit既可以输出适应不用client的界面，具体可以阅读一下JSF Spec；

这个理论上听起来很有道理，可是我觉得html是比JSF甚至java还要铁的标准，长远来看，手机等设备肯定是会首先主动支持html的,html的应用范围和周期可能比java长得多.我觉得替换render-kit基本是种神话，不知道目前有没有JSF->SWING，Flash的render.

156 楼 juzhibest 2009-04-10  

phoenixup 写道

cats_tiger 写道

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

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

我也是遇到这个问题.
我这1G+2核  开机之后只能运行 seam+jboss+eclipse  再加一个浏览器了.

内存已经寥寥了.

155 楼 murainwood 2009-04-02  

steeven 写道

JSF技术是server side的状态。命中注定不能用于高负载的internet site。
企业复杂应用的快速开发倒是很好。不过这个时候偶觉得echo gwt之类的技术更合适，用java写出web界面。更快。

个人鄙视一切手工写html方式，不易于维护扩展。除非有很好的IDE支持。

好吧，你去鄙视吧，只用Java写出Web界面的人，还真是非主流

154 楼 nychen2000 2009-04-02  

我粗浅研究过seam，感觉太重量级，我尤其不喜欢ejb。我2001年的时候被ejb1.0和后来的2.0搞得焦头烂额。现在的3.0虽然简单了很多很多，但是实在没有必要在发布时搞成EAR，直接POJO+ManagedBean多简单啊。

如果不用ejb，那seam就没有用的必要了。所以我们现在的组合是(JSF+facelet)+spring+hibernate。我觉得相当地爽，JSF+facelet页面很漂亮、模板化很出色，数据双向绑定很简单。spring里面的东西也很简单，基本就是自动生成的DAO。

前面很多网友提到jsf慢的问题，以我的经验来看可能不一定如此。我用jsf做过一个项目，这个项目是将原来的桌面程序改成Web方式，所以用户对系统反应速度的要求极其苛刻。

系统刚开始的时候确实有点卡壳，后来发现是jboss的rich faces引起的，我们废掉了rich faces的界面控件后速度大大提升，基本接近桌面程序了。

当然期间还有许多的优化措施，比如js缓存、数据库端优化等等。以我的经验判断，jsf是会多占用一些服务器端的内存，增加一些计算。但是，我们自己编写的垃圾代码大多数情况下比 jsf影响更大的多！

153 楼 zjsun 2009-03-26  

robbin 写道

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

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

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

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

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

疑惑一：JSF其实也仅仅是个规范而已，Tag自然有Tag的道理，从长远来看，以后的client不一定只是浏览器（能够识别html），如手机设备等，JSF的好处即是：如果你采用了JSF规范实现的tag，可以替换相应的render-kit既可以输出适应不用client的界面，具体可以阅读一下JSF Spec；

疑惑二：这个问题是不存在的，我用seam已有将近1年的时间，开发环境是eclipse，修改页面会自动deploy，无需重启server，当然我没有使用EJB3，而是pojo component+JPA（hibernate）


总的来说，seam确实方便灵活，seam还有很多精妙的地方楼主还没有提到（如seam的component在运行时被override的特性），但由于seam是一种全新的思路，而且整合了一些最新的spec，一般人刚开始时都难以上手和理解，所以我们要勇于打破常规和勇于否定，在驾驭这些框架或平台之后，我们需要思考的就是如何应用到我们实际的项目中去为用户解决实际的问题。 今天时间来不及，等我下次有机会再和大家讨论一下有关seam的一些心得。

152 楼 steeven 2009-03-07  

JSF技术是server side的状态。命中注定不能用于高负载的internet site。
企业复杂应用的快速开发倒是很好。不过这个时候偶觉得echo gwt之类的技术更合适，用java写出web界面。更快。

个人鄙视一切手工写html方式，不易于维护扩展。除非有很好的IDE支持。

151 楼 nbkangta 2009-01-15  

构建在JSF之上，就注定慢了...
除了表现层，其他都蛮不错

150 楼 fanfree 2008-12-18  

看了1个小时才看完；有没有人说说seam中更适合领域模型啊

149 楼 limingxi 2008-11-06  

个人觉得seam耦合性高了一点。

148 楼 hepeng421 2008-10-31  

jsf从来都觉得会性能问题，把所有的性能开支都放在服务器端；说实话别是把精力放在框架上呢，ssh的方式够用了，用新的功能就升级呀

147 楼 teateattt 2008-10-28  

seam & jsf 毕竟是一种快速开发（RPD）框架，并不是java web开发的主流方向，作为sun来说，只是用来填补“asp.net模式”的空白，关于javaweb的未来已经预测到会放弃客户端，别说jsf，“银光”都放弃了

146 楼 super_094 2008-10-14  

看了半个月的seam，但还是不敢用来做项目：（

145 楼 wuxiao_v 2008-10-12  

“在RoR流行之前，Java社区的主流还是非常讲究分层、架构、复用和模式，而比较忽视快速开发和简化架构的，其结果就是代码量大、开发周期长、架构相当烦琐。”

分层，架构，复用，模式为了构建有弹性的应用，从软件的整个生命周期来看会减少很多各方面的成本。不同规模的问题采用不同的解决方案，如果只是构建一个十分小的应用不用任何框架使用 jsp+servlet 最简化。jsf本事就是一个败笔“灵感”来自asp.net，但是在vs里随便用鼠标点两下就能实现数据绑定，jsf能行么。ejb就更不用说了，天生就是为分布式应用设计的，本质上就是解决大问题的，他的复杂性相信大家都有所了解，国内有几个项目是基于ejb的，北京满大街跑的程序员有几个会ejb有几个想学ejb。
        ejb运行于庞大的java应用服务器但是这个seam偏偏说自己擅长解决轻量级问题这本事就是十分矛盾的。
     也不知道这seam能走多远。

144 楼 bb74 2008-09-26  

我用SEAM做过一个项目，感觉还是不错的，开发效率上比spring要高很多，但性能还是个问题，不过这有可能是JSF造成的，调试的时候很多时候一个方法要调用多次，这一点没有struts那么流畅

143 楼 pikachu 2008-09-26  

qdzheng 写道

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

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

seam就是个胶水层

142 楼 pikachu 2008-09-26  

nimrob 写道

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

用seam吧。入了门绝对感到简单多了。

141 楼 key232323 2008-09-24  

难道开源这么久，还不如oracle n年前出的一个oaf？？webbean的标准怎么现在才出来啊？？