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

评论

60 楼 xiao0556 2008-07-08  

Anatorian 写道

fangshun 写道

xiao0556 写道

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白

其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！

可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。

不过用richfaces来做这种简单的ajax还有非常容易的，看下面的代码：

<a4j:region>
<h:inputText value="#{supplierAction.name}">
 <a4j:support event="onblur" reRender="addr" actionListener="#{supplierAction.findSupplierByName}" />
</h:inputText>
<h:outputText id="addr" value="#{supplierAction.supplier.name}"/>
</a4j:region>

当焦点离开了文本输入框时，引发一次ajax动作，输入框里的值被绑定到supplierAction的name属性上后，调用supplierAction.findSupplierByName()方法，查出的结果放到supplierAction.supplier上，然后重新生成(reRender) id为addr的页面部分。
用起来是不是很方便？
如果你要的功能,seam正好提供了，那最好，如果没有提供，那就有些麻烦了。不过seam在做企业应用方面，已能满足大部分的要求了。实际上www.seamframework.org这个外网的应用，也是用seam写的，看来如果功力足够，做一些外网应用也是可以的。

俺从06年末就开始用ajax的JSF组件库,IceFace是最早的放弃的.其实一直到现在也没有一个能完全适用的，只能自己写JSF组件来扩展。ajax的JSF组件库 并不是想像中的那么好用。我想如果有一年以上JSF开发经验的应该能体会到这点

59 楼 aidiyuxin 2008-07-08  

smilerain 写道

看个一点点jsf，感觉很差的一个东西，透明性，和可控性都不够好，我感说不会有很大浪花。seam 找jsf 配对，是一个错误。

现在国外JSF很火的。。。
星星浪花可以滔天～～
哈哈

58 楼 Anatorian 2008-07-08  

fangshun 写道

xiao0556 写道

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白

其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！

可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。

不过用richfaces来做这种简单的ajax还有非常容易的，看下面的代码：

<a4j:region>
<h:inputText value="#{supplierAction.name}">
 <a4j:support event="onblur" reRender="addr" actionListener="#{supplierAction.findSupplierByName}" />
</h:inputText>
<h:outputText id="addr" value="#{supplierAction.supplier.name}"/>
</a4j:region>

当焦点离开了文本输入框时，引发一次ajax动作，输入框里的值被绑定到supplierAction的name属性上后，调用supplierAction.findSupplierByName()方法，查出的结果放到supplierAction.supplier上，然后重新生成(reRender) id为addr的页面部分。
用起来是不是很方便？
如果你要的功能,seam正好提供了，那最好，如果没有提供，那就有些麻烦了。不过seam在做企业应用方面，已能满足大部分的要求了。实际上www.seamframework.org这个外网的应用，也是用seam写的，看来如果功力足够，做一些外网应用也是可以的。

57 楼 fangshun 2008-07-08  

xiao0556 写道

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白

其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！

56 楼 JeffreyHsu 2008-07-08  

robbin 写道

springhill 写道

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。

是的，我完全同意这种看法，企业应用架构的设计要求和互联网应用的架构设计要求完全不同。 在服务器端保存状态这是互联网应用的大忌，但是Seam这样用下来对于企业应用实现有状态的业务流程却看起来效果非常好。

企业应用的业务逻辑比互联网要复杂的多，良好的服务端状态机制对于复杂业务的开发非常有帮助，并且seam“深度集成”了相当多的企业开发的中间件比如规则引擎，工作流引擎，消息系统，远程访问，等等等。

而用来开发web的确有点烦，显得繁琐，在强调开发速度的互联网世界里显得有点重，你一个好创意出来，等你用seam隆重的搞出来，黄花菜都凉了

我现在搞得东西偏电子商务方面，业务还是有点复杂的，并且有数据整合的需要，所以暂时还是考虑用seam。如果是纯web2.0，建议还是用python, php等动态语言

55 楼 darkjune 2008-07-08  

Grails也是针对互联网应用的, Seam没有深入了解过,如果象前面朋友说的是主要针对企业开发的, 那在易用性和对页面的控制能力上肯定是不一样的,毕竟侧重不同

54 楼 xiao0556 2008-07-08  

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白

53 楼 pppppp 2008-07-08  

Anatorian 写道

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

现在Tapestry5已经可以和seam继承了，不一定非要JSF

52 楼 robbin 2008-07-08  

springhill 写道

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。

是的，我完全同意这种看法，企业应用架构的设计要求和互联网应用的架构设计要求完全不同。 在服务器端保存状态这是互联网应用的大忌，但是Seam这样用下来对于企业应用实现有状态的业务流程却看起来效果非常好。

51 楼 springhill 2008-07-08  

qingyujingyu427 写道

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

同意这位兄弟的观点，最近参加了一次QClub的活动，发现做企业级开发的人和做互联网应用的人，在思考问题的方式和想法上真的有很大的不同。Seam作为一个面向企业应用的框架，其设计思路更多的是考虑企业应用的诸多问题，所以需要大家在了解一个东西的时候，更多的应该先了解其定位。

50 楼 cswcafe 2008-07-08  

我的结论是目前Seam不能用在实际的项目中，太不成熟了BUG多多；等它成熟了可能这类框架已经不是主流了。

49 楼 qingyujingyu427 2008-07-08  

看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。

48 楼 cswcafe 2008-07-08  

各个组件的兼容性不好，有时一个版本没有问题，但更新到新出的小版本又出许多的小问题，和自家的JBOSS应用服务，绑定太紧，完全是一个为JBOSS应用服务开发的框架，独立性不强，还是SPRING好的，现在许多银行都用SPRING，我就是在银行系统上用SEAM出了许多问题，后悔啊。

47 楼 vieri122 2008-07-08  

支持EJB+JSF2.0的完美搭配！

46 楼 cswcafe 2008-07-08  

我用Seam 做过项目，很后悔用它，问题多多，还不成熟，Jboss的这些开源软件还有许多质量问题。

45 楼 phoenixup 2008-07-08  

打倒小日本 写道

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

JSF,SPRING,SEAM不是全有全无的选择，Seam的设计目的就是包裹JSF、EJB3.0~~JBoss怎么说来着，Seam的意义就在于缝合~~其意昭昭了~~

44 楼 winwa 2008-07-08  

打包开发ear文件其实是非常容易的事情啊,用MyEclipse6.5直接可以集成jboss等所有的应用服务器,无论修改ejb还是jsp,都不需要重启服务器和，自动部署,修改了马上可以看见效果

43 楼 bottom 2008-07-08  

To robbin,

引用

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

spring也有annotation的注入机制和组件声明机制，无须以往的大量XML配置，所以说不上麻烦。另外，俺也没有说你贬低了spring，俺说的是象“麻烦”之类的贬义词。

引用

Seam看起来没有这些问题，当然我现在还不太清楚Seam的底层实现机制。但是官方文档上面这是一个Seam被宣传的亮点，那应该就不会出现Spring那些问题了。

“看起来”，“还不太清楚”，“应该就不会”，看来你也没试过，怎么这么快就说“还是有很大不同”？如真要说不同，那只是“官方”与“非官方”的差别而已。

俺不是spring team的，也没有特意维护spring，以事论事，希望真理越辩越明而已。

42 楼 houwei 2008-07-07  

My solution  is :

Adobe Flex + Granite DS + Seam.

The  Presentation level Flex Should be  No.1 Choice in the RIA World, Maybe  in the  WWW World.

Granite DS is No.1  Technic  solution to implements AMF which  you can think about  it   as  a bridge between ActionScript and JAVA,

Seam  Crazy Gavin's Favorate  Baby. And the biggist benefit you can get  is Coverstional Component and Bijection.

Another thing  is  very powerful of Seam  is  Working with JBPM if you have a work flow  app to develop  you can try  Seam with  JBPM.



I almost  give up  Spring  solution  for my development. Because:
   1,  IOC : I hate the spring configration , I use Warp-persist/Guice   to replace it.
   2. I dont like  Spring  Security. It is too complicate.

   3. I rarely use  AOP and  other  spring sale point part: JMS.  Webservice, Remoting . etc.
 
I am still struggling  in my mind  between  EJB3(JPA Base) or Spring(J2EE).
     1. Which one  will  die first:
             EJB3: The reason should be  there is not  profit for  Giant Jerk(IBM, BEA).
             Spring(J2ee): I really think  spring  is out of date after java 5. and  I didnt see any  revelutionary  change  since  2004 which  spring became hot.  And Rod Johnson become a  CEO Not A CTO. He is more interesing  in  money than tech. Does this mean Spring  will die soon?
 

41 楼 smilerain 2008-07-07  

看个一点点jsf，感觉很差的一个东西，透明性，和可控性都不够好，我感说不会有很大浪花。seam 找jsf 配对，是一个错误。