seam再见了

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

评论

26 楼 hantsy 2009-05-10  

1314520ln 写道

估计LZ并没有深入了解seam

这么早就下结论.

这是正常的。。。
在以前公司，推行JUnit, TDD 时，一些所谓的公司核心技术力量开始说三道四，说不好那不好。
其实，几乎没有一个人在项目真正运用。
有的人连junit一次都没有使用过。
我后来看出了一些问题，为什么这些喜欢传统直接目测的方式，出现问题，就可以推三推四（因为这种环境下一时看不出是谁的代码出了问题），把责任首先推到别人头上。

不管楼主是使用 seam 还是 jsf ，都要了解它的运行原理，利用它的特点和优点进行开发。如果使用这些东西，首先都是将自己的思维放在第一位，什么框架都用不好。我无法想像，jsf 在你们项目中是如何运用的。

25 楼 SSailYang 2009-05-10  

我觉得 Seam 是不大适合 Web 开发的，而是适合一些企业开发。这里的 Web 开发指的是应用的客户只是一个人，这个客户同其他客户并没有什么协作关系。应用所提供的功能的工作流程也相对简单。对于这样的应用，Seam 优势是发挥不出来的。对于企业应用，有用客户之间的协作关系较强，工作流程相对复杂。这时，Seam 所提供的 Conversation、工作流以及其他特性都会这样的开发场景提供很多帮助。

24 楼 cyberblue 2009-04-30  

据说有运行在Java上的PHP解释器，不知道谁用过。

23 楼 sxlkk 2009-04-29  

biaoming 写道

web嘛，一定要轻。
我也用seam一段时间，和楼主一样感觉，效率问题。

其实快慢自己用一下就知道了，看到很多文章说这里好那里好，那只是看到了优点，缺点呢，一般都不会讲的，有关seam的文章只说到了提高开发效率，代码量少了，可在运行效率上没有说明啊。我这次放弃seam的最终原因就是运行效率低

22 楼 biaoming 2009-04-29  

web嘛，一定要轻。
我也用seam一段时间，和楼主一样感觉，效率问题。

21 楼 cyberblue 2009-04-29  

seemoon 写道

sxlkk 写道

举个不恰当的例子：seam跟jsf的关系有点像hibernate跟jdbc的关系差不多，你觉得hibernate在运行效率上会高于jdbc吗，而且hibernate的出现就是为了解决jdbc开发很麻烦的问题，seam也是如此吧。
    我用jboss-tool插件生成一个seam项目，他可以有个简单运行的界面的，我点击那些个页面就很慢，这是我说他慢的一个理由，自动生成的代码不会存在我编码效率低的问题而影响到它自身的运行效率，在一个就是看一下seam工程本身，它的结构很复杂，要加载一大堆的文件，能不慢吗？

seam&jsf ~ hibernate&jdbc ?
要加载一大堆的文件=慢？

用一下就知道了，比Apache MyFaces慢一半大概，还有Hibernate比TopLink慢了也将近一半，两样合到一块後果不堪设想。

20 楼 seemoon 2009-04-29  

sxlkk 写道

举个不恰当的例子：seam跟jsf的关系有点像hibernate跟jdbc的关系差不多，你觉得hibernate在运行效率上会高于jdbc吗，而且hibernate的出现就是为了解决jdbc开发很麻烦的问题，seam也是如此吧。
    我用jboss-tool插件生成一个seam项目，他可以有个简单运行的界面的，我点击那些个页面就很慢，这是我说他慢的一个理由，自动生成的代码不会存在我编码效率低的问题而影响到它自身的运行效率，在一个就是看一下seam工程本身，它的结构很复杂，要加载一大堆的文件，能不慢吗？

seam&jsf ~ hibernate&jdbc ?
要加载一大堆的文件=慢？

19 楼 1314520ln 2009-04-29  

估计LZ并没有深入了解seam

这么早就下结论.

18 楼 sxlkk 2009-04-29  

举个不恰当的例子：seam跟jsf的关系有点像hibernate跟jdbc的关系差不多，你觉得hibernate在运行效率上会高于jdbc吗，而且hibernate的出现就是为了解决jdbc开发很麻烦的问题，seam也是如此吧。
    我用jboss-tool插件生成一个seam项目，他可以有个简单运行的界面的，我点击那些个页面就很慢，这是我说他慢的一个理由，自动生成的代码不会存在我编码效率低的问题而影响到它自身的运行效率，在一个就是看一下seam工程本身，它的结构很复杂，要加载一大堆的文件，能不慢吗？

17 楼 daquan198163 2009-04-29  

16 楼 ThinkingInAll 2009-04-29  

没发觉seam效率很慢阿，倒是发觉richfaces真的很慢，不过还能接受

15 楼 ericxu131 2009-04-29  

sxlkk 写道

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

JAVA再见了

14 楼 seemoon 2009-04-29  

楼主认为前端是制约seam效率的主因，这让人比较疑惑，struts2框架在前端可以有多种选择，此效率不行完全可以考虑用另一种，seam也如是。另外为什么seam的开发效率要低于jsf?seam在很多方面应该是对javaee开发简单便利方向的增强，单单从seam(天织)的含义就能看出来。所以有人看不懂你写的纯属正常。

楼主可以再深入的探讨一下。

13 楼 fish4j 2009-04-29  

laochake 写道

Spring MVC 很简洁，(MultiActionController+JSP)

嗯,我也喜欢用 Spring MVC,Controller+FreeMarker

12 楼 laochake 2009-04-29  

Spring MVC 很简洁，(MultiActionController+JSP)

11 楼 1314520ln 2009-04-29  

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

seam本身是很好的东西.


你可以用seam+ext作项目.

10 楼 cgwangjun 2009-04-29  

嗯！ 开源来来去去

9 楼 hocus 2009-04-29  

刑天战士 写道

大多数时候应用的运行效率问题纯粹是因为数据库建模的原因……

和ORM工具的误用

8 楼 fins 2009-04-28  

seam可以算是 叫好不叫座的典范吗?
(纯疑问 )

7 楼 sxlkk 2009-04-28  

iamlibo 写道

不知道你们现在使用什么了？

现在用的是jsf+ejb