Wicket、Grails与JSF/seam, tapestry性能比较

09-09-16 banq
         

wicket beats grails jsf+seam tapestry一文对当前最流行几个表现层框架性能进行了比较,如下图:

1.Grails比Tapestry 更加产品化,这是因为Grails的文本质量要通俗易懂,看过Tapestry的文档的人确实比较难以

理解作者思路,Tapestry作者最近写了一个很学术的怪异模式,看了半天才大概明白是动态代理 懒加载之类。

2.Grails的性能需要提高。

3.Wicket是最快的,Tapestry紧随其后。

4. Seam + JSF 的Session使用量明显高于其他,每个Session大概760 KB.为什么这个指标很重要,因为在分布式

环境中,这些Session中数据是否分布拷贝到其他服务器上,如果是幂等的,可重新生成,就安全,否则服务器

之间Session复制就占据服务器大量处理能力。

5.tapestry网站宣称:在一些类似Tapestry框架中, 类如 Faces和Wicket, 页面结构是动态的, 必须保存更多数据在HttpSession.该文作者认为这个结论是不正确的。

个人评价:其实我们已经从Wicket和tapestry关于HttpSession口水仗看到基于服务器的表现层框架的一个误区:

在服务器端处理客户端状态的窘境,而REST倡导将客户端状态转移至客户端,这是一个方向性的不同创举啊,

所以,为了获得根本的高性能,以及高伸缩性,使用REST架构也许是个大趋势。其他不过是五十步笑百步。

[该贴被banq于2009-09-17 11:39修改过]



         

2
saharabear
2009-09-20 14:17

wicket用户漂过。wicket和rest并存,对外查询的基本上都是rest,有一些后台管理的用wicket,目前已经解决了100%的问题。但Wicket与其他框架的集成,不如Struts1/2之类的方便,这里主要是报表,工作流之类的框架,不代表其他的DI框架和Web框架。

Wicket扩展性很好,各种类抽象得相当不错。

JSF,谁用,我佩服谁,个人观点,能不用就不用。Seam也是。

Grails过去是玩具,现在开始走向正规。

tapestry看过3和4,再到了5居然又是大变脸,我不想折腾,就没再看过。学习曲线相对大一些,似乎不适合生产中找人来开发。

hantsy
2009-11-10 18:28

seam/jsf 还是比较有前途的,jsf 2.0 或许是走进寻常百姓家的第一步。。。

jsf 2.0 疯狂的吸引了其他扩展的一些特性,如ajax4jsf, richfaces, jsftemplate, icefaces等,可能是Java EE 6中特性增加最多的一个规范。

掌握jsf,我相信需要一定时间的(目前我正在练习jsf/seam),毕竟它的设计有些复杂,相对于基于action的框架。jsf 在java web 开发真正做到了组件复用,目前比较出名的组件包括,richfaces/ajax4jsf, icefaces, openfaces, primefaces, dojofaces, xulfaces, restfaces等,几乎覆盖了所有的ajax技术(dojo,yui,ext,jquery等),你不用写任何js代码可以做各种效果ajax页面,当然还有Myfaces家族产品。

seam的扩展性是很强的,不要想到seam就想到了jsf,其实在2.0早期,seam中已经集成了spring(可以调用spring bean), gwt, wicket等等的支持,tapestry5, metawidgets 等都有seam的扩展。

至于wicket,只是试用过,个人感觉功过参半,页面干净了,却需要复杂冗长的java代码来处理即使很简单的响应。

与 wicket 相比,如果我喜欢这种编程方式,我会选择vaadin(基于gwt,我觉得它可以脱离gwt),内置了页面模板,没有页面代码(当然你不喜欢它的样式,就可以自己定义页面样式),所有代码是java完成。

metawidgets 的方式也是不错,和xul编程类似。

jamesqiu
2009-12-05 10:51

Wicket 比较喜欢的,够优雅;开发起来感觉不错,有IDE完全支持,写代码心里踏实;

Grails 研究了一段时间,更改代码后重新装载还是慢,有时候甚至无效,完全没有淋漓爽快的感觉;Groovy的IDE代码分析检查也不行,得靠运行时检查调试大部分问题,不爽;

JSF和Tapestry没用过,没有发言权;