|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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好 好像是万能的一样 所以才发表一下意见 |
| 返回顶楼 |
 已被评为好帖! |
|
发表时间：2008-07-09
本人一只用seam开发，有一年多了吧
最开始时候用shale+jpa,也是基于jsf的，后来转到seam+jpa+a4j 做的是企业应用，不过这个东西页面复杂就很麻烦 要要不少圈子才能得到你想要的 正如楼上所说，做简单的表单堆砌的东西还可以。 不过要是和a4j 结合，还会好些，但还是不很喜欢这个东西，不如struts用的痛快 记得刚开始学习时候在这里发seam的帖子，还被删除了几回，呵呵 |
| 返回顶楼 | |
|
发表时间：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，在并发会话访问时保证状态的一致性，并对于操作同步执行！我的理解也仅止于此！ |
| 返回顶楼 | |
|
发表时间：2008-07-10
是 马老师？
|
| 返回顶楼 | |
|
发表时间：2008-07-10
nihongye 写道 不知道你是否理解错了seam说的，事务的提交必须等到渲染的完成这点是完全不成立的，事务可以手工，一般使用让spring的transactionmanager加上aop进行处理。
看了你链的hibernate文档，好像明白你说的aop进行处理的含义，seam的做法是请求处理阶段启动并完成一个事务，跳入到渲染阶段再启动和并完成一个事务，这样和jsf的请求处理阶段，渲染响应阶段正好想融合，可以很好解决spring的openSessionInView最终释放绑定的问题！ 估计你说的aop应该是在调用阶段，aop来提交一个事务，并且在启动一个新的事务面向渲染阶段！session对于一个请求始终存在！ |
| 返回顶楼 | |
|
发表时间：2008-07-10
Extended persistence context和openSessionInView的最大的不同是，Extended persistence context的session的存活时间要比OpensessionInView要长得多。前者能够跨越多次http request，而OpenSessionInView只能让session存活在一次请求之中。
|
| 返回顶楼 | |
|
发表时间：2008-07-10
一个框架，一个新特点，这也许就是推陈出新的动力吧。程序员就是这些动力脚下的牺牲品。
|
| 返回顶楼 | |
|
发表时间：2008-07-10
Anatorian 写道 Extended persistence context和openSessionInView的最大的不同是，Extended persistence context的session的存活时间要比OpensessionInView要长得多。前者能够跨越多次http request，而OpenSessionInView只能让session存活在一次请求之中。
这个讨论的主题是说jboss seam的。不对这个话题继续深入讨论了吧。感兴趣不妨查下jpa规范里面关于extended per...的定义。个人觉得conversation->conversasion persistence scope,OpensessionInView->request scope。都是在extended这个长命鬼的基础上做进一步的控制。 seam的特点是渲染阶段也启动了事务，关于这点，在我给出的hibenrate的链接上，对它的优点做了说明。 关于使用ThreadLocal绑定session。印象中jpa规范对ejb组件间的调用，context如和传播做了规定，猜测具体的实现离不开TheadLocal。 |
| 返回顶楼 | |
|
发表时间：2008-07-11
jsf1.x没有达到宣称的那么好。
|
| 返回顶楼 | |
|
发表时间：2008-07-11
每一种技术都有它的长处和短处，各取所长吧！
|
| 返回顶楼 | |
