我们公司做世界级的电信软件前端 只用struts
有些时候软件考究的不是优雅与否 先进与否 成熟最重要
我感觉struts还要生存好阵子
最近看了看tapestry,感觉尽量少的在html里面加入程序代码这个思想还可以,不过里面用到了不少反射,不知道这样对性能的影响是不是很大,再就是,下拉填充怎么感觉这么麻烦,不象asp.net的简单table也是很麻烦,还有一个html,一个page。
著名的TSS网站是使用Tapestry/Kodo JDO,但是TSS有时上去比较慢,有人开始找原因,Tapestry作者认为不是Tapestry问题:
http://howardlewisship.com/blog/2005/09/theserverside-software-problems.html
TSS经常发生丢贴和莫名其妙的问题,大家七嘴八舌,可见访问量一旦巨大,对技术考验就见真谛了:
http://www.theserverside.com/news/thread.tss?thread_id=36654
TSS的问题应该与tapestry没有直接的关系。
也不知道为何tss要用tapestry改版。实践中感觉tapestry非常不适合作web敏捷开发,尤其在强调表现层的项目。
是这样,性能问题发生在组件层和持久层可能性比较大,特别是持久层,从EJB2的BMP 到CMP 到Hibernate到JDO,都有人出现过性能缓慢的抱怨,可见这其中调教不是靠OO设计就能够完全对付的。
TSS上文章:Struts消失了吗?在最近一一次about.com的调查中,选择下一代开发框架时,好像Struts逐渐被抛弃了。谁是struts替代者呢?TSS上老外也七嘴八舌:
http://www.theserverside.com/news/thread.tss?thread_id=37365
我看对有人对表现层的框架调度产生的性能消耗产生担心。
本人不才实地测试也一把,发现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 合并了
相关讨论:
struts1 vs struts2
Struts2和Struts1有什么异同?struts1和Struts2现在项目应用的情况如何?
想不到banq也会把这么老的帖翻出来!!
struts2太复杂,不是view应该玩的东西。虽然实现很不错,想法很不错。在它应该控制的层次上做过头了。
不是功能越多越好,够用,简单才好用。复杂的东西或消失或简化吧(取自某某之blog,抱歉,忘记您的blog地址了)。