|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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存在脏数据的几率大增，实际情况是否有这个问题，容易处理吗？ |
| 返回顶楼 | |
|
发表时间：2008-07-08
我们在集群的时候也遇到了很大的问题,
多大的冲破都不够用(现在已经上5G了) 状态复制老是报错,特别是用上AJAX4J时 不知道怎么解决 |
| 返回顶楼 | |
|
发表时间：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. |
| 返回顶楼 | |
|
发表时间：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的职责进行更明确的划分！ |
| 返回顶楼 | |
|
发表时间：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多达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，刷新次数太多，反映慢,被直接毙了。 |
| 返回顶楼 | |
|
发表时间：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多达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。 |
| 返回顶楼 | |
|
发表时间：2008-07-09
引用 对于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做了明确的规定）？” |
| 返回顶楼 | |
|
发表时间：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对于开发企业应用还是不错的。 |
| 返回顶楼 | |
|
发表时间：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环境了 |
| 返回顶楼 | |
|
发表时间：2008-07-09
我发现我真的理解不了有些人的思维。 不知道从哪点能看出来
引用 "你一直强调ajax做的功能只是花哨"。
ADF有ajax功能，点击一个button时，我可以选择只刷新某个table或某个文本框或某个span等等。而且只需要改一个属性即可。 |
| 返回顶楼 | |
