blueoxygen 2005-10-11 16:59
我们公司做世界级的电信软件前端 只用struts
有些时候软件考究的不是优雅与否 先进与否 成熟最重要
我感觉struts还要生存好阵子
LoveVirus 2005-10-25 12:49
最近看了看tapestry,感觉尽量少的在html里面加入程序代码这个思想还可以，不过里面用到了不少反射，不知道这样对性能的影响是不是很大，再就是，下拉填充怎么感觉这么麻烦，不象asp.net的简单table也是很麻烦，还有一个html,一个page。
hgwnet 2005-10-26 21:29
TSS的问题应该与tapestry没有直接的关系。
也不知道为何tss要用tapestry改版。实践中感觉tapestry非常不适合作web敏捷开发，尤其在强调表现层的项目。
banq 2005-10-27 12:13
是这样，性能问题发生在组件层和持久层可能性比较大，特别是持久层，从EJB2的BMP 到CMP 到Hibernate到JDO，都有人出现过性能缓慢的抱怨，可见这其中调教不是靠OO设计就能够完全对付的。
clzhang 2005-11-28 23:39
我看对有人对表现层的框架调度产生的性能消耗产生担心。
本人不才实地测试也一把，发现struts其对性能的损失是极其小的。
说一下我用的工具和测试过程，
硬件配置: P4 2.6 1G内存。系统Linux 2.6内核。
软件上用:
struts 1.2.8
ibatis+MySql4.1 做数据库层
作了一个简单的新闻数据1000条记录和实际系统相去甚远。

在程序部分分别在下列关键点处加入时间输出。
1.在struts调度的前后分别加入的系统时间的日志输出。
2.请求用filter过滤了一道，在filter的chain.doFilter()前后加入的系统时间的日志输出。

测试方式:
在区域网的另一台机器上用apache带的 ab 压了500次请求.
分别测试了5次.

得出的测试结果是，调度层消耗的时间为1~2毫秒而整个请求完成的时间在100~200毫秒之间。再加上本身取得系统时间和打入日志的时间消耗，
我觉得调度层损失的性能几乎可以忽略不计。

clzhang 2005-11-28 23:45
毛主席说过: 一切从实际出发、实事求是!
商品经济发展的今天我也不要忘了他老人家真理!
blueoxygen 2005-11-29 13:09
时间还没过去太久 某些预言就已经meaningless
webwork 将合入 struts
呵呵，两个最强大的阵营的合并
看谁再说struts xxxx
rico 2005-11-29 16:19
webwork 已经和 struts 合并了
fyxruben 2008-05-31 12:34
想不到banq也会把这么老的帖翻出来！！
freebox 2008-06-01 15:49
struts2太复杂，不是view应该玩的东西。虽然实现很不错，想法很不错。在它应该控制的层次上做过头了。
不是功能越多越好，够用，简单才好用。复杂的东西或消失或简化吧（取自某某之blog，抱歉，忘记您的blog地址了）。