Java Web 框架 Tapestry

转载

mb5fdcaee2972df 2009-05-15 20:24:00

文章标签 html 客户端 struts 组件开发业务逻辑 文章分类 Html/CSS 前端开发

JSF和Tapestry的全面比较

为了对JSF和Tapestry进行全面的比较，让读者了解这两种框架各自的优缺点，以便于在自己的项目中，根据实际情况，选择合适的框架，对它们两者进行比较，总结了如下表分析比较。

	JSF	Tapestry
设计架构	跳转模型：Front Controller+组件化编程。	页面模型：Page Controller+组件化编程。
编程模型	业务逻辑：POJO的编程风格；页面逻辑：主要是JSP，也可以用HTML风格。	业务逻辑：Taperstry4需要继承基类；但Taperstry5就是POJO风格；页面逻辑：普通的HTML。
请求处理	由官方定义的六个步骤组成；	取决于Engine Service。
导航	通过faces-config.xml配置文件完成。	URL是全局的，没有额外的配置文件；除非显式跳转，所以行为都在本Page上。而跳转分两种： 1. DirectLink写在页面上 2. 在代码逻辑中定义页面跳转逻辑。
事件处理	页面定义事件发起；两种方式参数传递方式：一种分离传递；另一种通过FacesContext。	页面定义事件发起；直接赋予参数，没有参数个数限制；除此外还有内置的生命周期相关的event
组件状态	没有状态维护机制，每次request都从建组件。	提供组件状态的维护机制。
组件开发	基于JSP Tag的开发方式。	开发方式类似Page, 逻辑代码和页面分离，页面输出使用HTML。
视图	主要是JSP，也可以用HTML风格。	HTML
验证及转换	提供了多种方式支持，但客户端验证支持不好，同时在form一级的支持不好，通常需要项目自己定制。	同样提供多种方式支持；此外提供客户端的Validation；天然地支持form一级支持。
I18N	较好的支持。	很好的支持，额外提供预览功能。
可测试性	测试支持简单容易。	Tapestry4的测试不容易，不过Tapestry5的测试可以很简单。
扩展性	良好	良好
行业支持	JSF业界标准，业内厂商支持会比较多，不过未必不会出现EJB2的结局。	应用范围小于Struts，之前的版本学习曲线太高。
迁移性	从Struts迁移不难；	从Struts或者JSP迁移难度较大些。

结论

JSF是一个强大的且可扩展的框架，无疑它将会是很成功的。尽管它目前还有不少的缺陷。它致力于解决JSP模板问题的方向是正确的，但可能不是最好的方法。笔者认为，能提供丰富的组件选择，特别是像Tapestry一样基于属性模型的设计，也许将会更加的适合JSF未来的方向。同时，降低组件开发的难度，也应将是JSF努力的方向之一，可以将模板机制引入组件开发模型。而这方面，Facelets无疑是最成功的。

JSF只有在组件和事件机制这个概念上类似Tapestry，但不是Tapestry 那样是一个完全组件的框架，所以，如果读者做一个对页面要求灵活度相当高的系统，选用Tapestry是第一考虑。JSF 则适合在一般的数据页面录入的系统中,对一个新的系统，可以直接从JSF开始；如果需要切换，可以将JSF和Tapestry一起考虑。另外，JSF/Tapestry不只是支持HTML，也支持多种客户端语言如WML或XUI等。这二者之间关系：如果说Tapestry比较极端点，那么 JSF则比较中庸一点，中庸主义是Sun联盟的一贯策略。

总的来说，J2EE Web 框架目前处在一种群雄逐鹿的状态，没有一个绝对的领导者。Struts是最流行的，但是它的主架构师也是主要的开发者已经抛弃了它。被称为Struts取代者的JSF目前还没有获得足够的影响力。而同时，其他的框架如Tapestry正在慢慢开始流行。