robbin
- 浏览: 4821741 次
- 性别:
- 来自: 上海
-
博客专栏
-
-
robbin谈管理
浏览量：137080
文章分类
最新评论
-
xly1981：
领导者是团队的灵魂。深入一线的过程，包括代码review，能帮 ...
robbin谈管理：改造团队的经验(2) -
jiehuangwei：
像这种总结比较性的ppt文档可以多发啊
Web并发模型粗浅探讨 -
linux1308：
看完学习到了很多东西，感谢推荐！
推荐一篇很好的RoR部署方案性能评测 -
zweite：
直接对搜索的结果进行缓存是不是会更快一点呢
漫谈应用缓存的命中率问题 -
kaogua：
现在已经是ruby2.0了， 不知道这个的效率是怎么样的， 是 ...
Ruby作为服务器端应用已经成熟了
上周去见了一个朋友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开源框架里面最优秀的快速开发框架之一了。
不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。
openSessionInView模式正是如你下面说的在事务完结后，仍"保持实体的托管状态"。
早期的spring存在的问题是在hibernate事务管理器中：“在事务抛出异常后，它没清空托管的实体，从而导致view的渲染出现脏数据”。
我所说的脏数据的意思是“长业务处理，同时考虑业务处理人员的并发操作，从而converstaion不能及时的反映出当前的数据状态，seam在事务异常时自动清空托管实体（突然想起，在jpa规范的3.3.4 Transaction Rollback做了明确的规定）？”
JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白
其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！
怎么杜绝？我们不用ajax做出类似c/s的效果，根本无法通过验收。我们原来一个项目转b/s的时候，就是因为asp.net的表现能力不及c/s，刷新次数太多，反映慢,被直接毙了。
我只想问ajax安全吗？我就坚决认为ajax就是不要用在企业应用里。
要做到RIA，用flex吧。要不就C/S。
JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白
其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！
怎么杜绝？我们不用ajax做出类似c/s的效果，根本无法通过验收。我们原来一个项目转b/s的时候，就是因为asp.net的表现能力不及c/s，刷新次数太多，反映慢,被直接毙了。
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
我觉得将openSessionInView作为一种session的生命控制角度来看，与Extended persistence context,Seam-managed persistence contexts并无本质的不同，都是一样的opensessioninxxxx。所以一直觉得对opensessioninview的评价是很奇怪的（除了早期的spring的确存在问题外）。
另外问个问题：关于seam,因为convers...是较长生命期的session，导致session存在脏数据的几率大增，实际情况是否有这个问题，容易处理吗？
对于openSessionInView的问题应该是一直存在的，不是早期spring的问题，就像seam文档中所说，当使用openSessionInView模式，事务的提交必须等到渲染的完成，如果业务恰恰是在事务提交时出现了异常，那么客户端又怎么能知道呢？
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！
我的理解上Extended persistence context，Seam-managed persistence contexts和spring处理的openSessionInView方式上具有本质的不同，ejb的有状态处理模式恰恰和spring无状态形成了鲜明的对比。Extended persistence context并不是一个长事务存在！它只是保持实体的托管状态，seam基于此方式并引入到jsf的运行环境中（请求处理与渲染相分离的模式）可以很好的解决openSessionInView带来的问题！
conversation在设计上对于长会话状态会放置在session中，同时又能杜绝httpSession少有的并发问题，你说的脏数据问题我理解是不存在的。而且converstaion的长会话面向的是一次长业务处理，但不会对常驻会话的数据负责，所以conversation降为临时会话时，就会清理所有长会话数据，那么就和httpSession的职责进行更明确的划分！
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
你真不能老是拿jsf和seam做对比，seam提供的一整套解决方案，jsf仅仅是给出了可实现的规范而已，seam讲究是一种策略而jsf讲究的是一种机制，为什么基于jsf而衍生出来的框架那么多，而seam只有一个！
seam作者对于jsf的推崇是很热的，当你欣赏jsf规范的api时，就能不断感受到设计者们构思的优雅，它面向展现层提供了全方位的插接机制，基于良好对象模型的处理模式！
例如在jsf的配置中
SeamPhaseListener加入到phase-listener，seam就可以完全的融入jsf各个生命周期实现状态增强！
DelegatingVariableResolver扩展了variable-resolver，spring就可以主动将控管对象集成进jsf变量解析！
FaceletViewHandler替换了view-handler，就可以让jsf的视图部分重新由facelets进行模板化处理！
如果你有好的富客户端渲染方式，那么就创建自定义RenderKit替换default-render-kit-id，增强渲染的效果！
如果你想定制更高效的state机制，创建自定义StateManager替换它的state-manager！
如果你想定制自己的导航规则程序，创建自己的NavigationHandler来替换navigation-handler
...................
这些都为扩展框架留足了余地，你完全可以使用seam并without jsf，但是jsf对于seam完全就是解耦的！
I totally agree with you. Actually I am using Seam as a Backend State Bean in my current project.
I had a chance to talk Gavin King When the Seam release the first Beta version. And A general Question is Why not Struts-like base Framework( event spring MVC) to create Seam. His point was:
a, Struts Can't keep the status since the central Action servlet. But JSF was bornwith the status keeping Architechture.
b. JSF is The Standard. and UI Design Tools makes it easier to use. But he still admitted that the customize component is a disastor to creat Seam-base app.
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
我觉得将openSessionInView作为一种session的生命控制角度来看，与Extended persistence context,Seam-managed persistence contexts并无本质的不同，都是一样的opensessioninxxxx。所以一直觉得对opensessioninview的评价是很奇怪的（除了早期的spring的确存在问题外）。
另外问个问题：关于seam,因为convers...是较长生命期的session，导致session存在脏数据的几率大增，实际情况是否有这个问题，容易处理吗？
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
你真不能老是拿jsf和seam做对比，seam提供的一整套解决方案，jsf仅仅是给出了可实现的规范而已，seam讲究是一种策略而jsf讲究的是一种机制，为什么基于jsf而衍生出来的框架那么多，而seam只有一个！
seam作者对于jsf的推崇是很热的，当你欣赏jsf规范的api时，就能不断感受到设计者们构思的优雅，它面向展现层提供了全方位的插接机制，基于良好对象模型的处理模式！
例如在jsf的配置中
SeamPhaseListener加入到phase-listener，seam就可以完全的融入jsf各个生命周期实现状态增强！
DelegatingVariableResolver扩展了variable-resolver，spring就可以主动将控管对象集成进jsf变量解析！
FaceletViewHandler替换了view-handler，就可以让jsf的视图部分重新由facelets进行模板化处理！
如果你有好的富客户端渲染方式，那么就创建自定义RenderKit替换default-render-kit-id，增强渲染的效果！
如果你想定制更高效的state机制，创建自定义StateManager替换它的state-manager！
如果你想定制自己的导航规则程序，创建自己的NavigationHandler来替换navigation-handler
...................
这些都为扩展框架留足了余地，你完全可以使用seam并without jsf，但是jsf对于seam完全就是解耦的！
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
你知道java的历史么，java本来是为了家用电子嵌入式系统而开发出来的语言。结果呢，被竞争对手击败了，才转向了internet。如果我说java特别适合网络应用，你是不是该拿java被创造的历史来证明我是错的呢？
你也说SUN的本意是JSF用来击败struts等web开发框架， SUN做到了么？ 本意跟实际情况一样么？
而且JSF作为一个web开发框架， 跟"JSF非常适用企业应用"矛盾么？ 互联网应用有自己合适的web框架，企业应用有自己合适的web框架，这样有问题么？
如果你有实际经验的话，请用点实际的东西，列举几条详细的论点，来证明和推翻一些东西。不要用太虚太宽泛的表达。
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
你知道java的历史么，java本来是为了家用电子嵌入式系统而开发出来的语言。结果呢，被竞争对手击败了，才转向了internet。如果我说java特别适合网络应用，你是不是该拿java被创造的历史来证明我是错的呢？
你也说SUN的本意是JSF用来击败struts等web开发框架， SUN做到了么？ 本意跟实际情况一样么？
而且JSF作为一个web开发框架， 跟"JSF非常适用企业应用"矛盾么？ 互联网应用有自己合适的web框架，企业应用有自己合适的web框架，这样有问题么？
如果你有实际经验的话，请用点实际的东西，列举几条详细的论点，来证明和推翻一些东西。不要用太虚太宽泛的表达。
可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。
我感觉是你们开发方看得ajax太多了，一旦客户提出页面操作上的连续性，马上想你无刷新场景，别把它用的太多了，如果是基于jsf的js特效组件，是可以引入的，如果你们项目的大部分场景都是这种效果，那么我很难想象，客户的日常工作竟然喜欢在自己的工作平台上冲浪！
我个人认为，至少在目前，做企业应用的时候，大部分时候ajax只是改进用户体验的锦上添花的东西。这些js,并不是为了完成华而不实的特效，而是为了切实的帮助用户更轻松地使用软件。能实现这些简单实用的功能基本上就够用了，这也是我为什么认为seam在企业开发方面还是可取的原因。
说到底SEAM就是定位于做企业应用的，脱离这个目标来谈SEAM，我觉得没有什么意义。
SEAM的表现层用JSF，虽然不方便实现一些花哨的高级功能，但是做一些简单的表单足够了。SEAM的后端，则十分的强大，如果应用得当，开发效率确实能提高很多。 seam 2.0.2 bug已经很少了，有兴趣的朋友可以再试一下。
可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。
我感觉是你们开发方看得ajax太多了，一旦客户提出页面操作上的连续性，马上想你无刷新场景，别把它用的太多了，如果是基于jsf的js特效组件，是可以引入的，如果你们项目的大部分场景都是这种效果，那么我很难想象，客户的日常工作竟然喜欢在自己的工作平台上冲浪！
JSF多达6个的请求生命周期给开发带来很多麻烦，我开始用JSF的时候是很支持它的 特别是它的绑定机制。可是后来随着用户对交互要求的提高，用JSF真的是很受罪。有人说有facelts可以组件化开发，不知道说这句话的用没用过 这东西和JSF一样只是看起来很美化 它的继承只能有一层！完全做不到组件化开发 到后期用JSF写自定义组件更麻烦 要把ajax代码写到里面 调试起来真是恶梦。后来有一次用过Grails真的再也不想用jsf了 感觉是JSF太理想化了一点不靠近开发人员和EJB2一样。Grails这种框架才真是为了开发人员着想的 面对着Grails的易用性JSF的优点 感觉很苍白
其实你的抨击主要来自jsf，就是那六个生命周期不能轻松的建立与ajax的直接操作关系。用ajax不方便，就开始喊叫jsf不是东西了。我的理解，企业开发，尽量杜绝ajax，就是不方便怎么了！
其实你真的看见问题的本质了。如果不用ajax， JSF用起来效率还是可以的 我指的是开发效率。运行效率就不能保证了。还有一点如果seam+JSF和Portel集成的问题 大家不知道遇到过吗？ seam的对话环境在protel里是有问题的 还有N多Bug。我抨击seam的另一点就是在于和portel的集成 也许这不应该怪seam。但是我就是用着很弄受 在用Seam的一年多时间里 打了N多补丁 都不好升级了。现在还没敢升到2。0。 还有seam的注入本身是不错的，可是在用了JSF以后 @in 会引发很多，一个Bean里注入了N多组件。你调用一个Action的时候，如果这些组件没有全部初始化 会出错。当然如果说企业应用就是有状态的 都保存在内存里了 那就无所谓了。其实这样来说 我和qingyujingyu427的观点也是吻合的
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
写这个文章的目的是和大家一起交流一下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开源框架里面最优秀的快速开发框架之一了。
分享到：
评论
80 楼
qingyujingyu427
2008-07-09
To houwei:
1.你知道我的观点是什么吗？
请看我的第一个回复里的第一句话。我的整个回复都是在反驳那个观点。
2."JSF适用于企业应用"跟"JSF是一整套的企业应用解决方案"， 这两句话的意思一样么。
我看你的表达意思。好像我什么时候说过"JSF是一套完美的企业应用解决方案"似的。
我可以说一下我为什么觉得JSF很适用于企业应用。
1. 企业应用一般比较重视功能，一般数据表单和表格较多，界面一般简洁大方即可，不需要做的很花哨。当然还有好多别的特点，懒得说了。
2. JSF一般都是微软式傻瓜拖拽开发，开发飞快。基本每个JSF的实现都有强大的IDE支持，我觉得如果不用IDE去开发JSF，基本上用JSF也就没啥意义了。
seam我不太了解，JSF的实现只用过sun本身提供的和oracle的ADF faces。
举个实际的例子吧，比如现在要做个功能，查询某个作者发过的所有帖子，要带分页功能，sql已经提供。
如果让我用adf来做个功能的话 （adf比别的JSF实现多了data bingding，可能比别的JSF开发会更快一些。不过我觉得理论上标准的JSF实现，只要IDE做的够好，也可以做到开发这么快）。
1. 通过sql建立一个View Object或者 EJB的entity bean。
2. 建一个页面。
3. 拖动View Object或者entity bean到页面上，自动生成文本框，按钮，可分页的表格，及所有的bingding component，及配置文件。表格每页显示多少可配置。双击按钮，自动生成查询代码。
4. 运行页面。结束。
以上操作都是通过IDE操作。熟练的话可能大概5分钟之内就能做完这个功能吧。最需要时间的地方可能是怎么写出那条sql来。
由于JSF开发很快，加上企业应用的一些特点，我觉得JSF对于开发企业应用还是不错的。
1.你知道我的观点是什么吗？
请看我的第一个回复里的第一句话。我的整个回复都是在反驳那个观点。
2."JSF适用于企业应用"跟"JSF是一整套的企业应用解决方案"， 这两句话的意思一样么。
我看你的表达意思。好像我什么时候说过"JSF是一套完美的企业应用解决方案"似的。
我可以说一下我为什么觉得JSF很适用于企业应用。
1. 企业应用一般比较重视功能，一般数据表单和表格较多，界面一般简洁大方即可，不需要做的很花哨。当然还有好多别的特点，懒得说了。
2. JSF一般都是微软式傻瓜拖拽开发，开发飞快。基本每个JSF的实现都有强大的IDE支持，我觉得如果不用IDE去开发JSF，基本上用JSF也就没啥意义了。
seam我不太了解，JSF的实现只用过sun本身提供的和oracle的ADF faces。
举个实际的例子吧，比如现在要做个功能，查询某个作者发过的所有帖子，要带分页功能，sql已经提供。
如果让我用adf来做个功能的话 （adf比别的JSF实现多了data bingding，可能比别的JSF开发会更快一些。不过我觉得理论上标准的JSF实现，只要IDE做的够好，也可以做到开发这么快）。
1. 通过sql建立一个View Object或者 EJB的entity bean。
2. 建一个页面。
3. 拖动View Object或者entity bean到页面上，自动生成文本框，按钮，可分页的表格，及所有的bingding component，及配置文件。表格每页显示多少可配置。双击按钮，自动生成查询代码。
4. 运行页面。结束。
以上操作都是通过IDE操作。熟练的话可能大概5分钟之内就能做完这个功能吧。最需要时间的地方可能是怎么写出那条sql来。
由于JSF开发很快，加上企业应用的一些特点，我觉得JSF对于开发企业应用还是不错的。
79 楼
nihongye
2008-07-09
引用
对于openSessionInView的问题应该是一直存在的，不是早期spring的问题，就像seam文档中所说，当使用openSessionInView模式，事务的提交必须等到渲染的完成，如果业务恰恰是在事务提交时出现了异常，那么客户端又怎么能知道呢？
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！
不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。
openSessionInView模式正是如你下面说的在事务完结后，仍"保持实体的托管状态"。
早期的spring存在的问题是在hibernate事务管理器中：“在事务抛出异常后，它没清空托管的实体，从而导致view的渲染出现脏数据”。
引用
conversation在设计上对于长会话状态会放置在session中，同时又能杜绝httpSession少有的并发问题，你说的脏数据问题我理解是不存在的。而且converstaion的长会话面向的是一次长业务处理，但不会对常驻会话的数据负责，所以conversation降为临时会话时，就会清理所有长会话数据，那么就和httpSession的职责进行更明确的划分！
我所说的脏数据的意思是“长业务处理，同时考虑业务处理人员的并发操作，从而converstaion不能及时的反映出当前的数据状态，seam在事务异常时自动清空托管实体（突然想起，在jpa规范的3.3.4 Transaction Rollback做了明确的规定）？”
78 楼
terranhao
2008-07-09
slaser 写道
fangshun 写道
xiao0556 写道
qingyujingyu427 写道
看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判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做出类似c/s的效果，根本无法通过验收。我们原来一个项目转b/s的时候，就是因为asp.net的表现能力不及c/s，刷新次数太多，反映慢,被直接毙了。
我只想问ajax安全吗？我就坚决认为ajax就是不要用在企业应用里。
要做到RIA，用flex吧。要不就C/S。
77 楼
slaser
2008-07-09
fangshun 写道
xiao0556 写道
qingyujingyu427 写道
看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判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做出类似c/s的效果，根本无法通过验收。我们原来一个项目转b/s的时候，就是因为asp.net的表现能力不及c/s，刷新次数太多，反映慢,被直接毙了。
76 楼
fangshun
2008-07-08
nihongye 写道
fangshun 写道
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
我觉得将openSessionInView作为一种session的生命控制角度来看，与Extended persistence context,Seam-managed persistence contexts并无本质的不同，都是一样的opensessioninxxxx。所以一直觉得对opensessioninview的评价是很奇怪的（除了早期的spring的确存在问题外）。
另外问个问题：关于seam,因为convers...是较长生命期的session，导致session存在脏数据的几率大增，实际情况是否有这个问题，容易处理吗？
对于openSessionInView的问题应该是一直存在的，不是早期spring的问题，就像seam文档中所说，当使用openSessionInView模式，事务的提交必须等到渲染的完成，如果业务恰恰是在事务提交时出现了异常，那么客户端又怎么能知道呢？
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！
我的理解上Extended persistence context，Seam-managed persistence contexts和spring处理的openSessionInView方式上具有本质的不同，ejb的有状态处理模式恰恰和spring无状态形成了鲜明的对比。Extended persistence context并不是一个长事务存在！它只是保持实体的托管状态，seam基于此方式并引入到jsf的运行环境中（请求处理与渲染相分离的模式）可以很好的解决openSessionInView带来的问题！
conversation在设计上对于长会话状态会放置在session中，同时又能杜绝httpSession少有的并发问题，你说的脏数据问题我理解是不存在的。而且converstaion的长会话面向的是一次长业务处理，但不会对常驻会话的数据负责，所以conversation降为临时会话时，就会清理所有长会话数据，那么就和httpSession的职责进行更明确的划分！
75 楼
houwei
2008-07-08
fangshun 写道
houwei 写道
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
你真不能老是拿jsf和seam做对比，seam提供的一整套解决方案，jsf仅仅是给出了可实现的规范而已，seam讲究是一种策略而jsf讲究的是一种机制，为什么基于jsf而衍生出来的框架那么多，而seam只有一个！
seam作者对于jsf的推崇是很热的，当你欣赏jsf规范的api时，就能不断感受到设计者们构思的优雅，它面向展现层提供了全方位的插接机制，基于良好对象模型的处理模式！
例如在jsf的配置中
SeamPhaseListener加入到phase-listener，seam就可以完全的融入jsf各个生命周期实现状态增强！
DelegatingVariableResolver扩展了variable-resolver，spring就可以主动将控管对象集成进jsf变量解析！
FaceletViewHandler替换了view-handler，就可以让jsf的视图部分重新由facelets进行模板化处理！
如果你有好的富客户端渲染方式，那么就创建自定义RenderKit替换default-render-kit-id，增强渲染的效果！
如果你想定制更高效的state机制，创建自定义StateManager替换它的state-manager！
如果你想定制自己的导航规则程序，创建自己的NavigationHandler来替换navigation-handler
...................
这些都为扩展框架留足了余地，你完全可以使用seam并without jsf，但是jsf对于seam完全就是解耦的！
I totally agree with you. Actually I am using Seam as a Backend State Bean in my current project.
I had a chance to talk Gavin King When the Seam release the first Beta version. And A general Question is Why not Struts-like base Framework( event spring MVC) to create Seam. His point was:
a, Struts Can't keep the status since the central Action servlet. But JSF was bornwith the status keeping Architechture.
b. JSF is The Standard. and UI Design Tools makes it easier to use. But he still admitted that the customize component is a disastor to creat Seam-base app.
74 楼
larva
2008-07-08
我们在集群的时候也遇到了很大的问题,
多大的冲破都不够用(现在已经上5G了)
状态复制老是报错,特别是用上AJAX4J时
不知道怎么解决
多大的冲破都不够用(现在已经上5G了)
状态复制老是报错,特别是用上AJAX4J时
不知道怎么解决
73 楼
nihongye
2008-07-08
fangshun 写道
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
我觉得将openSessionInView作为一种session的生命控制角度来看，与Extended persistence context,Seam-managed persistence contexts并无本质的不同，都是一样的opensessioninxxxx。所以一直觉得对opensessioninview的评价是很奇怪的（除了早期的spring的确存在问题外）。
另外问个问题：关于seam,因为convers...是较长生命期的session，导致session存在脏数据的几率大增，实际情况是否有这个问题，容易处理吗？
72 楼
larva
2008-07-08
在高并发的访问时
在页面直接访问component数据时
很多时间取到的是空的,也没有任何异常
这是一个非常大的问题
在页面直接访问component数据时
很多时间取到的是空的,也没有任何异常
这是一个非常大的问题
71 楼
fangshun
2008-07-08
houwei 写道
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
你真不能老是拿jsf和seam做对比，seam提供的一整套解决方案，jsf仅仅是给出了可实现的规范而已，seam讲究是一种策略而jsf讲究的是一种机制，为什么基于jsf而衍生出来的框架那么多，而seam只有一个！
seam作者对于jsf的推崇是很热的，当你欣赏jsf规范的api时，就能不断感受到设计者们构思的优雅，它面向展现层提供了全方位的插接机制，基于良好对象模型的处理模式！
例如在jsf的配置中
SeamPhaseListener加入到phase-listener，seam就可以完全的融入jsf各个生命周期实现状态增强！
DelegatingVariableResolver扩展了variable-resolver，spring就可以主动将控管对象集成进jsf变量解析！
FaceletViewHandler替换了view-handler，就可以让jsf的视图部分重新由facelets进行模板化处理！
如果你有好的富客户端渲染方式，那么就创建自定义RenderKit替换default-render-kit-id，增强渲染的效果！
如果你想定制更高效的state机制，创建自定义StateManager替换它的state-manager！
如果你想定制自己的导航规则程序，创建自己的NavigationHandler来替换navigation-handler
...................
这些都为扩展框架留足了余地，你完全可以使用seam并without jsf，但是jsf对于seam完全就是解耦的！
70 楼
houwei
2008-07-08
qingyujingyu427 写道
houwei 写道
qingyujingyu427 写道
看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
你知道java的历史么，java本来是为了家用电子嵌入式系统而开发出来的语言。结果呢，被竞争对手击败了，才转向了internet。如果我说java特别适合网络应用，你是不是该拿java被创造的历史来证明我是错的呢？
你也说SUN的本意是JSF用来击败struts等web开发框架， SUN做到了么？ 本意跟实际情况一样么？
而且JSF作为一个web开发框架， 跟"JSF非常适用企业应用"矛盾么？ 互联网应用有自己合适的web框架，企业应用有自己合适的web框架，这样有问题么？
如果你有实际经验的话，请用点实际的东西，列举几条详细的论点，来证明和推翻一些东西。不要用太虚太宽泛的表达。
I mentioned you just try to use JSF to customize your own component , you will know how difficult to use the JSF without Seam.
，请用点实际的东西，列举几条详细的论点，
How about you write your JSF component or something else to prove your point .不要用太虚太宽泛的表达. then we can discuss the details.
My current project is based on Flex + Granite DS + Seam . But it is out of the scope of this discussing.
And I had experience to use JSF to develop WEBAPP. I also had experience to use Seam in another WEB APP/Eentrprise APP.
I never say Seam is not good solution. But Pure JSF is not. and It is proved.
I really want to you to give us a real example to get JSF for Enterprise App then the other Framework.
Could you do it ? Pls be a man
69 楼
orpheus
2008-07-08
重在掺合，多看，多学习，多总结
68 楼
hatedance
2008-07-08
我没用过seam，但是听起来entity bean和session bean似乎就是EJB。
67 楼
fangshun
2008-07-08
当使用seam的converstaion双射策略来解决焦点对象的保存，引用问题，将是非常的舒服，并且有效治疗了httpSession在服务端对象延续机制的弊端，这个特例也反映了seam正好适合对高性能要求不是很强烈企业应用领域，这一切如果没有jsf作为对象状态机制的建设，seam只会痛苦的在无状态机制，弱对象模型的其他表现层中挣扎。
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
同样g.king 的hibernate在spring的懒关系上也是很痛苦，无法把真正需要的东西延续下去，却在使用蹩脚的openSessionInView来掩盖，而ejb3的Extended persistence context经过seam的封装后的Seam-managed persistence contexts也许是唯一一个良好解决懒问题的体系了，seam集成jsf和ejb3不是作者本身的主观意思，而是框架发展的必然阶段！
66 楼
qingyujingyu427
2008-07-08
houwei 写道
qingyujingyu427 写道
看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
你知道java的历史么，java本来是为了家用电子嵌入式系统而开发出来的语言。结果呢，被竞争对手击败了，才转向了internet。如果我说java特别适合网络应用，你是不是该拿java被创造的历史来证明我是错的呢？
你也说SUN的本意是JSF用来击败struts等web开发框架， SUN做到了么？ 本意跟实际情况一样么？
而且JSF作为一个web开发框架， 跟"JSF非常适用企业应用"矛盾么？ 互联网应用有自己合适的web框架，企业应用有自己合适的web框架，这样有问题么？
如果你有实际经验的话，请用点实际的东西，列举几条详细的论点，来证明和推翻一些东西。不要用太虚太宽泛的表达。
65 楼
Anatorian
2008-07-08
fangshun 写道
Anatorian 写道
可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。
我感觉是你们开发方看得ajax太多了，一旦客户提出页面操作上的连续性，马上想你无刷新场景，别把它用的太多了，如果是基于jsf的js特效组件，是可以引入的，如果你们项目的大部分场景都是这种效果，那么我很难想象，客户的日常工作竟然喜欢在自己的工作平台上冲浪！
我个人认为，至少在目前，做企业应用的时候，大部分时候ajax只是改进用户体验的锦上添花的东西。这些js,并不是为了完成华而不实的特效，而是为了切实的帮助用户更轻松地使用软件。能实现这些简单实用的功能基本上就够用了，这也是我为什么认为seam在企业开发方面还是可取的原因。
说到底SEAM就是定位于做企业应用的，脱离这个目标来谈SEAM，我觉得没有什么意义。
SEAM的表现层用JSF，虽然不方便实现一些花哨的高级功能，但是做一些简单的表单足够了。SEAM的后端，则十分的强大，如果应用得当，开发效率确实能提高很多。 seam 2.0.2 bug已经很少了，有兴趣的朋友可以再试一下。
64 楼
fangshun
2008-07-08
Anatorian 写道
可惜用户和领导不会这么想。现在他们在互联网上用ajax多了去了，如果你不用，他们就会问，我选了品牌之后，后面就不能只列出这个品牌的产品吗？ 用户就是上帝呀。
我感觉是你们开发方看得ajax太多了，一旦客户提出页面操作上的连续性，马上想你无刷新场景，别把它用的太多了，如果是基于jsf的js特效组件，是可以引入的，如果你们项目的大部分场景都是这种效果，那么我很难想象，客户的日常工作竟然喜欢在自己的工作平台上冲浪！
63 楼
fangshun
2008-07-08
jsf的ajax组件化应用虽然被提到很高的程度来满足不同的胃口，但是我不认为这个级别的组件对于js本身还和开发者还有什么关系，开发使用的着重点仍然是在jsf组件的封装接口方面，所以，jsf即使封装了ajax它也应该叫jsf组件，而不是ajax组件，对于ajax易用问题除非在jsf前端提供一个类似facelets的js集成扩展框架来方便的与js交流，同时又能向facelets一样装饰出来一个简单级别的jsf组件，以保持组件化模式。
62 楼
xiao0556
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， 估计是以前看论坛里各位大佬天天批判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， JSF用起来效率还是可以的 我指的是开发效率。运行效率就不能保证了。还有一点如果seam+JSF和Portel集成的问题 大家不知道遇到过吗？ seam的对话环境在protel里是有问题的 还有N多Bug。我抨击seam的另一点就是在于和portel的集成 也许这不应该怪seam。但是我就是用着很弄受 在用Seam的一年多时间里 打了N多补丁 都不好升级了。现在还没敢升到2。0。 还有seam的注入本身是不错的，可是在用了JSF以后 @in 会引发很多，一个Bean里注入了N多组件。你调用一个Action的时候，如果这些组件没有全部初始化 会出错。当然如果说企业应用就是有状态的 都保存在内存里了 那就无所谓了。其实这样来说 我和qingyujingyu427的观点也是吻合的
61 楼
houwei
2008-07-08
qingyujingyu427 写道
看到一些回帖的人的观点都是： seam作为jboss的一个这么完美的开源项目，可惜啊，就是用了JSF这个落后丑陋违反潮流的东西。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
不知道这些人有没有真正的了解够JSF， 估计是以前看论坛里各位大佬天天批判JSF，人云亦云，自己也没去了解也没有实践过就开始鄙视它了。 其实Robbin所说的seam的前4个优点都是由JSF决定的，任何JSF的实现都有这些优点。如果你想让seam不用JSF而又要保留这些优点，那只能让seam项目组自己去创造一个类似于JSF的标准而又要更先进了，看来seam项目组并不觉得这是一件简单的事情，或者他们觉得JSF很可以，总之他们没有去这么做。
个人认为，JSF非常适用于企业应用，如果你大多数的经验都是开发互联网的经验，那最好也就别来评判JSF了。
JSF非常适用于企业应用
Do you really know JSF History? Do you know SUN use JSF to Beat Struts for the WEB APP Develope Framework?
This is not a Funny Joke "JSF非常适用企业应用".
Seam could be a solution for Enterprise APP JSF absolutely not the one.
Just think about customize your own component base on JSF/Facelate without Seam . Could you still say JSF is "JSF非常适用企用"?
发表评论
-
WebObjects的来龙去脉
2012-06-08 15:30 7616在知乎上回答的一个问题：http://www.zhihu.co ... -
缓存技术浅谈
2010-09-24 18:08 21813有我在两年前写的一个培训的ppt，是介绍缓存知识的。有兴趣的可 ... -
对领域模型实现的总结性观点
2008-11-30 15:16 19562陶文发起的对领域模型 ... -
Spring Application Platform - SpringSource的应用服务器发布
2008-05-05 17:04 68952008年的5.1劳动节，Spring ... -
Warp framework - 一个相当有前途的Java轻量级Web开发框架
2008-03-06 15:24 22568Warp framework 是最近刚刚 ... -
Google Android会成为手机领域的微软Windows吗？
2007-11-16 17:23 9644Google gPhone手机的传言已经沸沸扬扬好几个月了，然 ... -
Java已经过时了吗？
2007-07-02 15:43 59723在四年以前，当我开始 ... -
Java开源框架发展的遐想
2007-05-23 00:04 34812上周末在杭州网侠大会做演讲的时候，我说：Java开源框架的革命 ... -
漫谈应用缓存的命中率问题
2007-05-09 14:19 26466这篇文章源自于： http://www.iteye.com/ ... -
为什么ORM性能比iBATIS好？
2007-05-06 11:16 34523缓存是有很多层次的，有web server前端缓存，有动态页面 ... -
点评Grails vs RoR
2007-03-30 17:49 8285Grails的革新和RoR相比，非常不彻底，很多地方兼容Jav ... -
缓存简述
2007-03-30 09:55 12263缓存实现的层面有很多： 1、对象缓存 由ORM框架提供，透明 ... -
JRuby0.9.8，正式宣布支持ruby on rails
2007-03-07 10:35 15668http://jruby.codehaus.org/ 自从S ... -
domain model的延伸讨论
2007-03-03 01:17 40714domain model，又称为领域模型，是Java企业应用讨 ... -
可以开始用Struts2.0了
2007-02-27 14:56 56103http://struts.apache.org/ Apac ... -
Google Guice - 比Spring快100倍的IoC容器
2007-02-27 14:46 58239http://code.google.com/p/google ... -
Spring2.0和EJB3.0随谈
2007-02-08 14:26 18464Spring自从2003年发布以来 ... -
Java程序员的推荐阅读书籍
2007-02-07 20:12 101367《Java程序员的推荐阅读 ... -
应该如何正确使用Quartz
2006-12-27 11:40 34238对于Web容器来说，最忌讳应用程序私自启动线程，自行进行线程调 ... -
静态类型语言的优势究竟是什么？
2006-11-13 10:03 33501在参与这个讨论的过程中，产生了一个新的话题，很想和大家探讨一下 ...
相关推荐
《JBoss Seam：超越Java EE的简易与强大》是一本深度探索JBoss Seam框架的权威著作，由Michael Yuan和Thomas Heute共同撰写。本书聚焦于JBoss Seam框架，旨在为读者提供一个全面、深入的理解，以掌握其在企业级应用...
标题中的“Jboss seam3 实战”表明，本文将重点介绍JBoss Seam框架的第三个版本的实际应用。JBoss Seam是一个开源的Java EE框架，它通过依赖注入和会话模型，简化了基于Java EE的企业级应用开发。Seam框架为开发者...
标题：JBoss Seam入门介绍 描述：本文将详细介绍JBoss Seam框架的核心概念、关键特性以及如何构建基于Seam的应用程序。Seam作为一个企业级Java Web应用框架，它将Java EE和JSF无缝集成，旨在填补Java EE 5.0中缺失...
**JBoss Seam组件中文手册** **一、Seam框架概述** Seam是一个开源的企业级Java框架，由JBoss公司开发，旨在简化Java EE应用程序的开发。它将多种技术如JavaServer Faces (JSF)，Java Persistence API (JPA)，EJB 3...
### JBoss Seam中文版知识点详解 #### JBoss Seam简介 JBoss Seam是一个强大的企业级应用开发框架，基于Java EE标准，特别强调简化Web应用的开发流程。它通过整合多种技术如JSF、EJB 3.0等，提供了一种更为高效、...
**JBoss Seam 中文文档集合概述** JBoss Seam 是一个开源的应用框架，它结合了JavaServer Faces (JSF)、Java Persistence API (JPA)、Enterprise JavaBeans (EJB) 3.0 和其他Java EE组件，旨在简化企业级开发。这个...
### JBoss Seam Eclipse 安装与配置详解 #### 一、引言 本文将详细介绍如何在 Windows XP 系统环境下，使用 Eclipse IDE 进行 JBoss Seam 的开发准备工作及环境配置。JBoss Seam 是一款基于 Java 的企业级应用框架...
【JBoss Seam】是Java企业级应用开发框架，它整合了JSF（JavaServer Faces）、EJB（Enterprise JavaBeans）3.0、JPA（Java Persistence API）以及一系列其他技术，为开发人员提供了一个强大的全栈式解决方案。Seam...
整理自jboss seam 中文站，压缩为chm格式，便于广大jboss seam爱好者阅读，所有版权归jboss seam中文站所有。
### JBoss Seam 2.01GA REF DOC #### 引言：JBoss Seam概览与功能介绍 JBoss Seam 是一个为简化企业级 Java 应用开发而设计的框架。它结合了 JavaServer Faces (JSF)、Java Persistence API (JPA) 和 Java ...
### 深入浅出JBoss Seam：整合与强化Java EE框架 #### 一、引言 JBoss Seam是一款基于Java EE 5.0的轻量级框架，它旨在简化企业级Web应用的开发过程，并增强应用的可扩展性和开发者的生产力。本文将详细介绍JBoss ...
JBOSS_SEAM配置
- **本教程**：主要介绍了JBoss Seam的基本概念、核心组件以及通过一系列示例项目来学习Seam的实际应用。 #### 二、Seam基础知识与实例分析 ##### 2.1 第一个Seam应用：注册示例 - **实体类**：`User.java`定义了...
这是中文手册，Seam为持久化集成了JPA和Hibernate 3，为轻量化的异步性集成了EJB Timer Service和Quartz，为工作流集成了jBPM，为业务规则集成了JBoss规则，为电子邮件集成了Meldware Mail，为完整的文本搜索集成了...
【JBoss Seam 2.0文档详解】 JBoss Seam 是一个开源的企业级开发框架，它旨在简化Java EE应用的开发过程，特别是在Web和富互联网应用程序（Rich Internet Applications, RIA）领域。Seam 2.0是其重要的版本，提供了...
《深入浅出JBoss Seam》 JBoss Seam是一个旨在简化企业级Web应用开发的轻量级框架，它补充和完善了Java EE 5.0的标准。Java EE 5.0虽然包含了EJB 3.0和JSF 1.2等核心框架，但它们各自独立，缺乏统一的编程模型。...
java jboss seam jboss-seam-selectitems
[TipTec Development] JSF & Facelets & JBoss Seam 核心技术 (英文版) [TipTec Development] Essential JSF, Facelets & JBoss Seam (E-Book) ☆ 出版信息：☆ [作者信息] Kent Ka Iok Tong [出版机构] TipTec ...