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

核心提示：[前言]：从2000年开始的MVC模式框架Struts看来将要被基于组件的事件驱动模型类框架替代，JSF和Tapestry都是新一代可能成为Struts的终结者，Struts终结者?对比组件框架技术tapestry，

[前言]：从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，网站大的如：