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

评论

100 楼 Acaleph 2008-07-10  

一个框架，一个新特点，这也许就是推陈出新的动力吧。程序员就是这些动力脚下的牺牲品。

99 楼 Anatorian 2008-07-10  

Extended persistence context和openSessionInView的最大的不同是，Extended persistence context的session的存活时间要比OpensessionInView要长得多。前者能够跨越多次http request，而OpenSessionInView只能让session存活在一次请求之中。

98 楼 fangshun 2008-07-10  

nihongye 写道

不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。

看了你链的hibernate文档，好像明白你说的aop进行处理的含义，seam的做法是请求处理阶段启动并完成一个事务，跳入到渲染阶段再启动和并完成一个事务，这样和jsf的请求处理阶段，渲染响应阶段正好想融合，可以很好解决spring的openSessionInView最终释放绑定的问题！
估计你说的aop应该是在调用阶段，aop来提交一个事务，并且在启动一个新的事务面向渲染阶段！session对于一个请求始终存在！

97 楼 hhw2000 2008-07-10  

是 马老师？

96 楼 fangshun 2008-07-10  

nihongye 写道

引用

对于openSessionInView的问题应该是一直存在的，不是早期spring的问题，就像seam文档中所说，当使用openSessionInView模式，事务的提交必须等到渲染的完成，如果业务恰恰是在事务提交时出现了异常，那么客户端又怎么能知道呢？
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！

不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。
openSessionInView模式正是如你下面说的在事务完结后，仍"保持实体的托管状态"。
早期的spring存在的问题是在hibernate事务管理器中：“在事务抛出异常后，它没清空托管的实体，从而导致view的渲染出现脏数据”。

引用

conversation在设计上对于长会话状态会放置在session中，同时又能杜绝httpSession少有的并发问题，你说的脏数据问题我理解是不存在的。而且converstaion的长会话面向的是一次长业务处理，但不会对常驻会话的数据负责，所以conversation降为临时会话时，就会清理所有长会话数据，那么就和httpSession的职责进行更明确的划分！

我所说的脏数据的意思是“长业务处理，同时考虑业务处理人员的并发操作，从而converstaion不能及时的反映出当前的数据状态，seam在事务异常时自动清空托管实体（突然想起，在jpa规范的3.3.4 Transaction Rollback做了明确的规定）？”

对于spring的openSessionInView问题，它的机制是不变的，最终渲染完页面才进行session.flush,我所说的事务提交就是对象进入数据库的那一刻，这里出现异常是常见的！而你所讲的aop处理，我不知道是如何实现？是不是在某一方法调用上终止掉整个状态！

在一次webapp请求中openSessionInView可以等效为保持实体的托管状态，那多次请求呢？一次长的业务处理呢？openSessionInView绑定在线程变量上，难道下一个线程还会给同一会话的人吗？我这里明确表达的意思是：ejb的有状态与和spring的无状态在处理上的不同。Extended persistence context和openSessionInView在状态保存的行为上是相同的，都是最终flush，因为背后的推手都是hibernate思想。但是当建立在ejb的有状态会话bean之上，托管状态不仅可以延续，而且不会因为spring的无状态必须依靠threadLocal而带来的种种不良问题！这时候有状态模型是作为一个独立的单元来进行操做的！我认为无状态问题是迟早要暴露出它的不足的，过多的依赖httpSession只会阻碍业务组件化的发展！

我理解有误，想到web层的httpSession了，我的理解对于状态机制最大的问题可能就是你所说的不同用户处理同一业务，带来的数据不同步问题，你可以看看seam文档，seam的convernates能做到对绑定在其上的有状态会话bean，在并发会话访问时保证状态的一致性，并对于操作同步执行！我的理解也仅止于此！

95 楼 vtrtbb 2008-07-09  

本人一只用seam开发，有一年多了吧
最开始时候用shale+jpa,也是基于jsf的，后来转到seam+jpa+a4j
做的是企业应用，不过这个东西页面复杂就很麻烦
要要不少圈子才能得到你想要的
正如楼上所说，做简单的表单堆砌的东西还可以。
不过要是和a4j 结合，还会好些，但还是不很喜欢这个东西，不如struts用的痛快

记得刚开始学习时候在这里发seam的帖子，还被删除了几回，呵呵

94 楼 Anatorian 2008-07-09  

nihongye 写道

Anatorian 写道

谢谢nihongye MM的指点。

客气啊，我男的。
http://www.hibernate.org/43.html
中的Can I commit the transaction before rendering the view?说的问题，值得spring借鉴

图片这么漂亮！以为是个美女！

93 楼 xiao0556 2008-07-09  

qingyujingyu427 写道

To xiao0556:
1. 我开始从来没提过ajax，而你好像对我的观点持相反意见，然后用ajax来反驳我的观点。
2. 我不认为JSF和ajax是一个级别的东西，他们有什么可比较之处。既然你有许多的JSF经验，难道你认为你说的ajax的那段话很有道理么？
3. 帖900多行代码到帖子里大家看着都不舒服。不太清楚贴这些代码有什么意义。证明你用过JSF？
4. 关于弹出窗口的问题。在adf里弹出窗口关闭时，可以刷新整个父窗口，也可以选择性的刷新某个或几个区域。我一开始已经说了我对seam不熟，所以用adf举例。看你的描述，或许seam的JSF实现不够好或者你们用的有问题？
5. JSF只是一个标准。每个厂商的实现都不一样，可能有的好，有的坏。如果我开发了一套实现，你觉得很烂，但并不能说明JSF不好。像以前大家批判JSF都是集中在批判状态存在服务器端的问题，我认为这样辩论是可以的。而你说了个这么细节的问题，而我也没看出来你是想用这个问题到底来证明JSF的哪个特点不好。

这样讨论好像回到正轨了

其实我一直在强调一点就是jsf做复杂交互的应用是不舒服，也许能做出来但是代价太高 就想上面写的那900多行代码的封装的JSF组件。我提ajax也是基于这一点 因为jsf的富客户端解决方案就是基于ajax实现的 jsf本身把状态都放在服务器端了，每一次操作都要请求服务器 这种模式根本不能很好的和ajax的模式相配合。普通的ajax请求也很难发给JSF的后台Bean

我认为seam 思想很好粘合的各层也很平滑 如果能和JSF解藕就更好了 但1.X版本的很不成熟。2.0没用过不知道怎么样了。
任何技术都有其适用的场景和不适用的场景，如果没有复杂交互的大部分是表单的应用seam＋JSF是很适用的。以浏览为主的应用用它就有点得不偿失，复杂交互的应用又是力不从心。

我提细节问题也许不是时机，但是真的是实际中发生的问题 很多时候一下就卡住了 才想JSF原来不是想像的那么好用。

我看很多人说seam+JSF好 好像是万能的一样 所以才发表一下意见

92 楼 nihongye 2008-07-09  

Anatorian 写道

谢谢nihongye MM的指点。

客气啊，我男的。
http://www.hibernate.org/43.html
中的Can I commit the transaction before rendering the view?说的问题，值得spring借鉴

91 楼 qingyujingyu427 2008-07-09  

To xiao0556:
1. 我开始从来没提过ajax，而你好像对我的观点持相反意见，然后用ajax来反驳我的观点。
2. 我不认为JSF和ajax是一个级别的东西，他们有什么可比较之处。既然你有许多的JSF经验，难道你认为你说的ajax的那段话很有道理么？
3. 帖900多行代码到帖子里大家看着都不舒服。不太清楚贴这些代码有什么意义。证明你用过JSF？
4. 关于弹出窗口的问题。在adf里弹出窗口关闭时，可以刷新整个父窗口，也可以选择性的刷新某个或几个区域。我一开始已经说了我对seam不熟，所以用adf举例。看你的描述，或许seam的JSF实现不够好或者你们用的有问题？
5. JSF只是一个标准。每个厂商的实现都不一样，可能有的好，有的坏。如果我开发了一套实现，你觉得很烂，但并不能说明JSF不好。像以前大家批判JSF都是集中在批判状态存在服务器端的问题，我认为这样辩论是可以的。而你说了个这么细节的问题，而我也没看出来你是想用这个问题到底来证明JSF的哪个特点不好。

90 楼 Anatorian 2008-07-09  

nihongye 写道

引用

This pattern is usually implemented as a single transaction which spans the entire request.

usually，写这段文字的人分明没真正使用过spring，使用spring的多数是搞一个Service类，然后Service类的方法作为事务的边界。一样的，即使一个request，多个事务也是一样ok的。事务完成后，session以never flush的形式保持到view渲染完成后关闭。

引用

spring的 persistence-context 一定是 transaction-scope的吗？ 事务结束，session也关闭？

transaction scope,extended-scope是在jpa才有的概念，hibernate里根本没有。
在没有open session的时候，spring的管理的session可以理解为transaction-scope的。但有了外部open session了，则不是。

引用

但是事务提交后，并不关闭session, 如果事务提交失败，会导致session的缓存里有脏数据吗？

清除托管对象，并不需要关闭session，session.clear就ok了。改动的对象为托管对象，事务失败后，后续的查询见到的对象还是这个托管对象，所以事务失败后，清除托管对象这点是很正确的。

谢谢nihongye MM的指点。看来在处理单次request的时候，spring经过配置后确实能够完成和seam同样的功能。也就是，在处理request之前开始session，在执行spring bean里的的业务方法的前后开启和提交事务，在完成页面渲染后关闭session。
但是很可惜，在用jsf的时候，处理业务逻辑，处理结果页面的渲染，是在后一个request里完成的。POST的时候调用业务方法，处理完后发送一个redirect，让客户端跳转到处理结果页面，客户端收到302后，用GET请求指定页面，这时服务端才渲染上一次处理的结果呢。在这种情况下，spring opensessioninview如何处理呢？这种情况下如果不能让hibernate session 跨越这次跳越，而是在下一次GET的时候又开始新的session，那么不是得做一大堆的重新从数据库里刷新托管对象的操作？

我觉得在与hibernate配合这一方面，seam确实做得比spring要好。不是说spring做不到，而是seam在这方面更易用。

89 楼 xiao0556 2008-07-09  

qingyujingyu427 写道

xiao0556 写道

引用

ADF有ajax功能，点击一个button时，我可以选择只刷新某个table或某个文本框或某个span等等。而且只需要改一个属性即可。

从这点就可以看出来，你真的没实际做过。也没有讨论的心要的。这样的贴子也没什么必要回了 大家都是在空口说白话 怎么说都行。

你在空口说白话，我没有。
另外，你觉得JSF跟ajax有什么可比较的么？你知道什么是JSF，什么是ajax么？

本来不想回这个贴了，不过你这样说我有点不开心 我做JSF这么长时间了怎么就不知道JSF是什么了？ 我不想搞人身攻击 也不希望别人攻击我 只用实际的例子和代码说话。上面的例子 你修改数据的时候 无非是弹出窗口和 跳转页面。那我想问一下 你弹出窗口修改完数据后 怎么刷新父窗口？ 你跳转就跳出protel了 就算跳不出去，你跳回来查询条件没了，第几页也没了 怎么办？你可以把状态存起来 可是跳转的时候一但出去protel环境就不是一个session了。问题是可以解决但不是你说的那么简单？你说的例子 只能是当例子 真正的开发是不会那样简单的。我们的环境是在protel＋seam里，对话环境是seam提的一个重要功能 但在protel里基本不能用 后来自己打补丁 可以用了但是也不是很稳定 保险的作法是每次都传cid 多么麻烦 真正用起seam来如果你应用交互要求不高 还是可以的 但是一但对复杂交互要求高了 有一大堆的坑等着你。关于我说的例子 我们是封装了一个弹出窗口的JSF组件解决的 可以刷新窗口的区域 可以开启对话环境。

88 楼 nihongye 2008-07-09  

引用

This pattern is usually implemented as a single transaction which spans the entire request.

usually，写这段文字的人分明没真正使用过spring，使用spring的多数是搞一个Service类，然后Service类的方法作为事务的边界。一样的，即使一个request，多个事务也是一样ok的。事务完成后，session以never flush的形式保持到view渲染完成后关闭。

引用

spring的 persistence-context 一定是 transaction-scope的吗？ 事务结束，session也关闭？

transaction scope,extended-scope是在jpa才有的概念，hibernate里根本没有。
在没有open session的时候，spring的管理的session可以理解为transaction-scope的。但有了外部open session了，则不是。

引用

但是事务提交后，并不关闭session, 如果事务提交失败，会导致session的缓存里有脏数据吗？

清除托管对象，并不需要关闭session，session.clear就ok了。改动的对象为托管对象，事务失败后，后续的查询见到的对象还是这个托管对象，所以事务失败后，清除托管对象这点是很正确的。

87 楼 qingyujingyu427 2008-07-09  

xiao0556 写道

引用

ADF有ajax功能，点击一个button时，我可以选择只刷新某个table或某个文本框或某个span等等。而且只需要改一个属性即可。

从这点就可以看出来，你真的没实际做过。也没有讨论的心要的。这样的贴子也没什么必要回了 大家都是在空口说白话 怎么说都行。

你在空口说白话，我没有。
另外，你觉得JSF跟ajax有什么可比较的么？你知道什么是JSF，什么是ajax么？

86 楼 Anatorian 2008-07-09  

nihongye 写道

引用

对于openSessionInView的问题应该是一直存在的，不是早期spring的问题，就像seam文档中所说，当使用openSessionInView模式，事务的提交必须等到渲染的完成，如果业务恰恰是在事务提交时出现了异常，那么客户端又怎么能知道呢？
也许是我孤陋寡闻不知道spring是怎么重新实现了这一模式，敬请答案！

不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。
openSessionInView模式正是如你下面说的在事务完结后，仍"保持实体的托管状态"。
早期的spring存在的问题是在hibernate事务管理器中：“在事务抛出异常后，它没清空托管的实体，从而导致view的渲染出现脏数据”。

引用

conversation在设计上对于长会话状态会放置在session中，同时又能杜绝httpSession少有的并发问题，你说的脏数据问题我理解是不存在的。而且converstaion的长会话面向的是一次长业务处理，但不会对常驻会话的数据负责，所以conversation降为临时会话时，就会清理所有长会话数据，那么就和httpSession的职责进行更明确的划分！

我所说的脏数据的意思是“长业务处理，同时考虑业务处理人员的并发操作，从而converstaion不能及时的反映出当前的数据状态，seam在事务异常时自动清空托管实体（突然想起，在jpa规范的3.3.4 Transaction Rollback做了明确的规定）？”

看看seam文档里的这段话：
EJB session beans feature declarative transaction management. The EJB container is able to start a transaction transparently when the bean is invoked, and end it when the invocation ends. If we write a session bean method that acts as a JSF action listener, we can do all the work associated with that action in one transaction, and be sure that it is committed or rolled back when we finish processing the action. This is a great feature, and all that is needed by some Seam applications.

However, there is a problem with this approach. A Seam application may not perform all data access for a request from a single method call to a session bean.

    *

      The request might require processing by several loosly-coupled components, each of which is called independently from the web layer. It is common to see several or even many calls per request from the web layer to EJB components in Seam.
    *

      Rendering of the view might require lazy fetching of associations.

The more transactions per request, the more likely we are to encounter atomicity and isolation problems when our application is processing many concurrent requests. Certainly, all write operations should occur in the same transaction!

Hibernate users developed the "open session in view" pattern to work around this problem. In the Hibernate community, "open session in view" was historically even more important because frameworks like Spring use transaction-scoped persistence contexts. So rendering the view would cause LazyInitializationExceptions when unfetched associations were accessed.

This pattern is usually implemented as a single transaction which spans the entire request. There are several problems with this implementation, the most serious being that we can never be sure that a transaction is successful until we commit it—but by the time the "open session in view" transaction is committed, the view is fully rendered, and the rendered response may already have been flushed to the client. How can we notify the user that their transaction was unsuccessful?

Seam solves both the transaction isolation problem and the association fetching problem, while working around the problems with "open session in view". The solution comes in two parts:

    *

      use an extended persistence context that is scoped to the conversation, instead of to the transaction
    *

      use two transactions per request; the first spans the beginning of the restore view phase (some transaction managers begin the transaction later at the beginning of the apply request vaues phase) until the end of the invoke application phase; the second spans the render response phase

spring的 persistence-context 一定是 transaction-scope的吗？ 事务结束，session也关闭？ 如果是这样，那OpenSessionInView确实可能出现页面渲染结束，但是事务没有提交成功，错语信息无法传达给用户的问题。如果OpenSessionInView,但是事务提交后，并不关闭session, 如果事务提交失败，会导致session的缓存里有脏数据吗？

就算不用conversation，在高并发的时候，一样有可能出现读脏数据的，除非对数据库做悲观锁，不然都有可能在你提交数据之前，别人已经改动过数据。关键是有多大的并发量，出现这种情况的机率有多大，以及出这种情况后会不会导致数据库出现不完整数据。在发生机率不是很高的情况下，用乐观锁，我觉得就够用了。
Conversation主要的好处是，扩大了session的生命期，减少发生LazyInitializationException，同时Conversation可以当作是一个很好缓存，把业务处理过程的中间数据放在其中，最后一把提交。我们的项目里就有这样一个场景，用户需要创建一份建议书，而建议书里包含很多合同的草稿，有些合同草稿是必要的，有些是不必要，有些是数目定死的，有些是任意数目的，我们用一个页面流程来让用户完成对这份建议书的创建，但是直到用户最终决定要保存的时候，才能把这份建议书放到数据库中，因为不能存在不完整的建议书，不能存在没有建议书的合同草稿。这个场景下，用conversation就相当的方便的，在用户最终提交前，数据都是放到conversation中的，用户在最后提交的时候，我们再通一个transaction把数据放到数据库中。更可贵的是，由于conversation可以并发，一个用户可以同时编辑数份建议书，而不相冲突，虽然我们项目中还没有给用户提供这样功能，但是conversation确实有这样的能力，这也是seam引以为荣的工作区概念。如果没有conversation，都塞到session中，将会相当的麻烦，因为那样的话，我们还得要控制对SESSION的并发访问，控制何时清理这些数据。而Conversation帮我们完成并发控制，并在conversation终止时自动清理数据，而且conversation往往两三分钟就超时了，要比session要容易清理得多，因为session往往超时时间很长的。

85 楼 xiao0556 2008-07-09  

引用

ADF有ajax功能，点击一个button时，我可以选择只刷新某个table或某个文本框或某个span等等。而且只需要改一个属性即可。

从这点就可以看出来，你真的没实际做过。也没有讨论的心要的。这样的贴子也没什么必要回了 大家都是在空口说白话 怎么说都行。

84 楼 nethaoke 2008-07-09  

接触了一段时间的jsf 用netbeans做开发 发现jsf还挺不错  尤其netbeans自带的数据绑定 代码生成 并对jsf周期进行封装 使我们的业务逻辑非常清晰 事件机制 增加了交互性 但自带的那个jsf库是生成dojo代码 所以运行速度慢 但是你可以修改源代码 有自带的html现实  稍微修改一下就行了 当然netbeans对电脑配置要求高  当然netbeans也可以很多优化的  多了解点 就不会说jsf怎么 怎么不好了

83 楼 cyberblue 2008-07-09  

JSF的确很方便，当界面上一次操作的数据量过大时，可以直接把实体Bean给Map过去。
如果需要校验的话可以使用Seam的特殊校验功能，或者可以找人单独做校验的程序，不过做这个很难受，一天8小时下来累得基本上不行了。

82 楼 qingyujingyu427 2008-07-09  

我发现我真的理解不了有些人的思维。 不知道从哪点能看出来

引用

"你一直强调ajax做的功能只是花哨"。

ADF有ajax功能，点击一个button时，我可以选择只刷新某个table或某个文本框或某个span等等。而且只需要改一个属性即可。

81 楼 xiao0556 2008-07-09  

qingyujingyu427 写道

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对于开发企业应用还是不错的。

你一直强调ajax做的功能只是花哨，那我根据你的需求改成一个比较实际的需求（我做过的）。你查询出来的数据分页显示并且可以编辑、删除、修改，查询条件有很多，用户在到某一页中改了某条数据切换回来的时候 查询条件和页数都不变 但是数据已经变为最新的了。而且是在protel环境里 你一转发就出protel环境了