Struts终结者?对比组件框架技术tapestry

1/5/2008来源:Java教程人气:6243

  [前言]:从2000年开始的MVC模式框架Struts看来将要被基于组件的事件驱动模型类框架替代,JSF和Tapestry都是新一代可能成为Struts的终结者。

  JSF和Tapestry都是基于页面组件技术的开发框架,但jsf基于jsp,仍然是jsp架构,开发维护起来非常麻烦。tapestry则不同,是基于servlet的一种完全页面组件化的开发框架,而且现在已经非常成熟,目前已经推出t4.0-beta2。

  页面开发走向组建化是一种越来越明显的趋势,这方面tapestry可以说是引导了这个方向,也许是sun太厉害,jsf一出生就得到大家的关注,不过顺此东风,tapestry的用户社区比以前更加繁荣了:

  http://news.gmane.org/gmane.comp.java.tapestry.user

  tapestry有很多范例出色,参看它的官方网站:

  http://jakarta.apache.org/tapestry/

  若想致力于web页面的开发,个人觉得jsp/serlvet是首要精通的,至于选择框架,则是一件费精力的事情。框架的目的是为了简化开发流程,提高生产效率,典型的框架如turbine、struts、webwork、jsf、tapestry等。如何选择框架是一个经久不衰的讨论,没有多年的实践经验是难以作出实际评价和最终抉择的。愚以为turbine过于厚重,无论是开发速度还是运行速度都令人难以接受,2.4M1到现在快一年还是M!,运行起来真是满如蜗牛,打开一个页面要等浏览器的地球要转上半圈,这也许要归功于velocity解析和没有页面缓存的功劳了。还有就是扩展性、可维护性等,实际上都很差,象它的核心类Turbine,居然定义为final!实际开发起来还不如我自己实现的velocity+servlet+filter框架效率高,速度快。


  struts,webwork实际都是jsp的MVC包装,无法摆脱jsp页面难以维护的烦恼,也许开发起来快,但维护呢?还有就是美工人员,他们都得懂jsp。实际的mvc分工在页面这块还是打了折扣。

jsf,在一定程度上借鉴了tapestry的组件思想,但大项目应用中狂多的标签封装和定义把你搞疯也得把机器搞疯,估算有两大弊端:运行速度相对慢和页面维护相对复杂。

  最后是tapestry,唯一的难度是理解它的组件开发方法,理解的转变就好比从过程开发到OO开发一样,但对初学者无所谓,一张白纸总是轻易上画的。

  选择tapestry有如下几大优点:

  1、最彻底的MVC开发框架,页面代码全部由Html标准标签组成,页面美工人员无须了解非凡的标签定义。

  2、可重用组件开发节省开发资源,一句话:越开发越轻松

  3、优秀的页面流转开发。传统方式都是基于URL实现激活页面流转,而tapstry除了此方式,你还可象开发普通java类一样实现page页面流,更重要的是,还可由此实现页面类的复用。

  4、丰富的组件资源。除了官方维护的资源外,还可找到一大堆的tapestry组件库。

  5、超强的扩展性。tapestry是一个真正的开放性架构,说白了,你觉得哪个服务不爽,你就可写个替代它。

  6、生命力超强,不断的自我更新、发展。tapestry4.0与3.0相比简直就是另一个飞跃,如支持jdk1.5的Annotations,仅这点开源产品中目前还只看到一个hibernate;支持portlet JSR-168,又一个顺应潮流的web开发支持。规划中的4.1将支持页面静态化,这不正是众多开发人员的另个期待吗?


  7、tapestry的开发人员稳定。不是一个两个人在那里单打独斗,而是有一群人在开发和支持tapestry的进程。

  8、tapestry技术成熟吗?基于tapestry的软件和大网站已经很多了,国外的:软件如SeaView内容治理系统、WidenTM Digital Asset Management System,网站大的如: