seam再见了

经过一段时间的seam开发，感觉seam用着挺好的，代码写起来还是很方便的，而且代码量确实如介绍的那样，比jsf+EJB开发少了很多，而且会话Bean作为jsf的后台很方便的去操作业务逻辑，但是我在做seam到现在遇到一个致命的错误——运行效率，是它让项目经理放弃了seam开发的一个主要原因，其他原因有很多了，比如说js的编码，js要写到注释中（这里用的是facelets而不是jsp），对myface的tree2的支持，对fckeditor的支持，等等，一系列的原因导致最终放弃了seam，自己也觉得挺可惜的，也投入了很多的精力在seam中，但是在项目的全局考虑来说现在放弃也是一个比较好的选择，因为现在开发的是公司的一个平台，对代码的安全性，和效率方面要求比较高，所以seam的上线运行还是个未知数，所以最终还是没有冒这个险。呵呵，就说这么多吧，seam再见了

评论

46 楼 cqwww 2010-03-26  

有前公司也是用的ejb3+jboss seam+自己的JS 框架

那个慢啊，启动慢，调试慢，。。。。。 一天都做不了多少事。

45 楼 love_seam 2010-03-24  

1314520ln 写道

LZ,你说到seam效率问题,主要出在icefaces等的问题吧,页面运行效率低,尤其运用ajax后.

seam本身是很好的东西.


你可以用seam+ext作项目.

的确是这样!我实战过.把richfaces全部去除了,这东西超级慢,生成的JS太大了！！！

44 楼 imlsq 2010-03-22  

seam 这种垃圾框架，还有人在用，我使用1.5年了，上个月终于把所有的代码从seam转移到spring上了。

seam谁用谁知道是垃圾，就是那个JSF+seam的，就让人崩溃。具体我就不详细了，如果大家想折腾，可以选用

43 楼 zxg_javaeye 2010-03-22  

1314520ln 写道

LZ,你说到seam效率问题,主要出在icefaces等的问题吧,页面运行效率低,尤其运用ajax后.

seam本身是很好的东西.


你可以用seam+ext作项目.

我们就用这个，遇到一个问题是，在把po传到前台的时候onetomany的lazy数据不能自动获取，这导致为了传输数据到前台显示，制造了大量的dto，还有大量的转换代码（之前用的属性copy包，后来发现慢得吐血，就手写了），前台传送数据到后台的时候，也要先从DTO转换到PO，而且前台会<s:remote >很多类，请问高手有什么方法能解决这个问题，或者什么好的建议。

42 楼 wsc830719 2009-12-20  

请问，我想做个交互能力强的OA系统，是ice好还是rich好呢？

效率问题可以忽略。因为OA，登录人数不会太多。
主要就是功能的实现上，比如哪个功能强大，而且实现起来又相对容易？
我看到rich的推送是假推，ice倒是真推，不过做起来有些复杂，需要很多配置、编码等工作。
哪个在不失简单性的情况下，更能做到逼近客户端软件的体验呢？
如果两个使用上差不多，哪个更能逼近客户端软件的效果？
多谢各位。

41 楼 wsc830719 2009-12-20  

.......新手路过。  前几个月刚把icefaces学了点。 想做个交互能力比得上客户端软件的办公室OA。 前几天，了解了下jsf2.0 以及richfaces 还有seam，觉得seam都被视为规范了，应该不错，转而我不学icefaces了，学起了richfaces，马上就把所有组件浏览完了。这下。。。。。。我又开始犹豫了。。

40 楼 berlou 2009-11-02  

补充一点， 我们是在顶级公司的平台产品项目上应用Seam的， Seam的性能是论证过的， 所以我一直坚持在自己的代码上找问题， 而不是不求甚解放弃Seam。
网上有很多工具和资料可以帮助解决问题。
另外Seam不只是支持RichFaces， 它还推荐用iceface替代RichFaces， 不过我没研究。

39 楼 berlou 2009-11-02  

Seam和RichFaces是可以调优的， 不知道楼主遇到什么具体问题了， 可以交流交流。
Seam的BypassInterceptor这个Annotation是要非常注意使用的， 如果忘记这个， 性能不可能好， 每次调用都10个8个的interceptor去拦截能好么？
这个是正确使用的问题， 不是Seam本身的问题， 还有RichFaces的一些特性其实前端未必用到， 推荐的做法是能用标准component解决的尽量不用richfaces， 另外通过YUI的测试报告来看， 尽量使用RichFaces的单文件js和css配置，减少HTTP请求次数。
我说的这点也是献丑， 我也在研究提高Seam的性能， 可以交流交流。
我觉得Seam之于JSF并不比Hibernate之于JDBC差， 相反， Seam很多地方做的我觉得比Spring优秀。

38 楼 larva 2009-11-02  

<p>我觉得不是你讲的那样,我们一直都在用,而且我们的系统是廷大的那种,每天流量应该也在50到100w,而且广告策略下载计算量都是相当大面复杂的,扣费也是要求错误率很底的那种,<br><img src="http://dl.iteye.com/upload/attachment/163265/5e7bdeae-a51f-343b-852f-bd28fce92970.jpg" alt=""><br> </p>

37 楼 yangbo 2009-09-08  

附件是jboss seam的一个压力测试报告，比较旧，但是可以参考看看。

36 楼 InnocentBoy 2009-07-01  

还有点，个人觉得seam对有状态会话bean的管理还是不错的。至少维护它的生命周期，对话生命周期。

35 楼 InnocentBoy 2009-07-01  

我正在看ejb3.0和seam。但是具体的应用还是开始做，icefaces + ejb3.0 + seam。

34 楼 danni505 2009-06-17  

我现在也在用jsf+ejb1.2+jsp+jstl+servlet

33 楼 cauxu 2009-06-16  

这东西运行个DEMO都这么慢

32 楼 wzjin 2009-06-16  

不知楼上的各位达人是否做了项目的充分的性能方面的跟踪和调优？

31 楼 fangshun 2009-05-12  

sxlkk 写道

经过一段时间的seam开发，感觉seam用着挺好的，代码写起来还是很方便的，而且代码量确实如介绍的那<script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/themes/advanced/langs/zh.js"></script><script type="text/javascript" src="http://www.iteye.com/javascripts/tinymce/plugins/javaeye/langs/zh.js"></script>样，比jsf+EJB开发少了很多，而且会话Bean作为jsf的后台很方便的去操作业务逻辑，但是我在做seam到现在遇到一个致命的错误——运行效率，是它让项目经理放弃了seam开发的一个主要原因，其他原因有很多了，比如说js的编码，js要写到注释中（这里用的是facelets而不是jsp），对myface的tree2的支持，对fckeditor的支持，等等，一系列的原因导致最终放弃了seam，自己也觉得挺可惜的，也投入了很多的精力在seam中，但是在项目的全局考虑来说现在放弃也是一个比较好的选择，因为现在开发的是公司的一个平台，对代码的安全性，和效率方面要求比较高，所以seam的上线运行还是个未知数，所以最终还是没有冒这个险。呵呵，就说这么多吧，seam再见了

我没有使用到ejb，仅从seam+jsf这样组合方面我没有感觉到是seam如此的慢。
seam有以下的增强，当然也就会产生效率消耗：
1.seam给jsf框架的变量解析链增加自己的变量解析环节，也就是每个变量处理都会经过seam变量解析处理！
2.seam在jsf的生命周期的每个阶段加入了监听器，使得每个阶段有一点点效率损失！
3.seam对jsf的backing bean 也就是seam的 component加入了元数据定义（大量的@...），那么处理这些元数据定义的机制就是利用了aop，在每次component的方法调用时刻，其实都会去执行包在component上的层层拦截器（seam的拦截器，和spring的很像，也可以自定义拦截器，加载到backing bean/component上）！
4.还有一些，我没有说到

当然了我相信你的设计是面向企业用户的，不是互联网用户，而且你的框架可以说是最低效的做法！
1.facelet的加入会比纯标记更慢
2.ajax+jsf的机制每次对一个或多个区域的操作都有可能多次请求jsf后台，导致jsf每次都要经历一个完整的生命周期处理，所以要合理并细心的控制ajax+jsf的代码。
3.seam的加入引入了消耗。
4.jsf本身不是一个非常高效的平台，由于它的监听机制导致组件的频繁访问，尤其要当心你的程序在调用组件的isRendered的方法时是否有资源消耗的操作，因为isRendered往往会在一次请求中频繁的被访问到！
5.ejb的使用也有更高的资源消耗。


但是这些共同使用可以打造一个高效的，复用性强的开发环境（请确定是ejb3），但是就不要在web环境下考虑了肯定会慢的。

30 楼 cyberblue 2009-05-12  

stenlylee 写道

很多对Seam不了解的人都在说Seam的效率不行，实际上真正有几个坚持用Seam开发完真实的项目然后测试过的？仅仅在开发的时候测试运行感觉运行慢，就说实际上线必然慢。前端用了RichFaces的确效率有降低，但是那不是Seam的问题。

虽然我也没有实际测试过具体Seam的效率怎么样，但是我只看实际运营的情况，我们公司用Seam开发的几个项目，最终在客户那里稳定运行以后，没有人感觉到效率问题。

开发过程中的效率问题的确是比较郁闷的，因为开发的时候，尤其是调试测试的时候，经常要重启容器，首次启动都要加载很多东西，并且对内存的要求也比较高。

大概做的不是互联网吧，办公室里的行业软件一般对UI的效率要求不高，有的甚至没有UI，如果并发访问太多的话就看出差距了。

29 楼 stenlylee 2009-05-11  

很多对Seam不了解的人都在说Seam的效率不行，实际上真正有几个坚持用Seam开发完真实的项目然后测试过的？仅仅在开发的时候测试运行感觉运行慢，就说实际上线必然慢。前端用了RichFaces的确效率有降低，但是那不是Seam的问题。

虽然我也没有实际测试过具体Seam的效率怎么样，但是我只看实际运营的情况，我们公司用Seam开发的几个项目，最终在客户那里稳定运行以后，没有人感觉到效率问题。

开发过程中的效率问题的确是比较郁闷的，因为开发的时候，尤其是调试测试的时候，经常要重启容器，首次启动都要加载很多东西，并且对内存的要求也比较高。

28 楼 stenlylee 2009-05-11  

楼主提到的问题纯粹是由于对Seam的不了解造成的，不是Seam的原因
不过Seam由于国内用的人太少，很多具体应用的解决办法并不是很符合国内大多数开发人员的习惯而已，也仅仅是由于习惯而已。

27 楼 nychen2000 2009-05-11  

seam没有经验，不过richfaces实在太慢，
强烈建议不要用。