我们公司做世界级的电信软件前端 只用struts
有些时候软件考究的不是优雅与否 先进与否 成熟最重要
我感觉struts还要生存好阵子

最近看了看tapestry,感觉尽量少的在html里面加入程序代码这个思想还可以,不过里面用到了不少反射,不知道这样对性能的影响是不是很大,再就是,下拉填充怎么感觉这么麻烦,不象asp.net的简单table也是很麻烦,还有一个html,一个page。

TSS的问题应该与tapestry没有直接的关系。
也不知道为何tss要用tapestry改版。实践中感觉tapestry非常不适合作web敏捷开发,尤其在强调表现层的项目。

是这样,性能问题发生在组件层和持久层可能性比较大,特别是持久层,从EJB2的BMP 到CMP 到Hibernate到JDO,都有人出现过性能缓慢的抱怨,可见这其中调教不是靠OO设计就能够完全对付的。

我看对有人对表现层的框架调度产生的性能消耗产生担心。
本人不才实地测试也一把,发现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毫秒之间。再加上本身取得系统时间和打入日志的时间消耗,
我觉得调度层损失的性能几乎可以忽略不计。

毛主席说过: 一切从实际出发、实事求是!
商品经济发展的今天我也不要忘了他老人家真理!

时间还没过去太久 某些预言就已经meaningless
webwork 将合入 struts
呵呵,两个最强大的阵营的合并
看谁再说struts xxxx

webwork 已经和 struts 合并了

想不到banq也会把这么老的帖翻出来!!

struts2太复杂,不是view应该玩的东西。虽然实现很不错,想法很不错。在它应该控制的层次上做过头了。
不是功能越多越好,够用,简单才好用。复杂的东西或消失或简化吧(取自某某之blog,抱歉,忘记您的blog地址了)。