Tapestry和JSF的比较

这篇文章主要介绍“Tapestry和JSF的比较”，在日常操作中，相信很多人在Tapestry和JSF的比较问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Tapestry和JSF的比较”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

1．JSF和Tapestry性能方面

JSF

从测试数据可以看出在只使用JSF及JSF自定义组件的情况下,webmail demo应用速度最快，200用户并发访问的响应时间为1.8秒，基本上可以达到servlet + jsp的性能。

使用JSF + 5个Facelet composition组件的情况下，webmail demo应用仍可达到200用户并发访问的响应时间为2.6秒的性能。

使用JSF + 20个Facelet composition组件的情况下,webmail demo应用可达到200用户并发访问的响应时间为3.1秒的性能。

如果在业务层方法没有大的效率问题、并在压力较大的页面适当使用缓存的情况下，JSF应用程序可以达到在dell 2850机器上100-200并发5秒内响应的性能

Tapestry

从测试数据可以看到tapestry在使用相同数量框架自身提供组件的情况下，运行效率比JSF明显要低一些，但也算是在可以接受的范围内。

2．JSF和Tapestry开发方面

JSF

JSF对servlet API进行了封装，程序员在使用组件做JSF应用程序的开发时基本上不需要直接操作HttpRequest和HttpResponse,并且对用户输入验证，手机等其它设备（通过rendererKit），多语言(通过资源文件方式)和换肤（通过rendererKit）的支持都有相应的封装，可以方便的实现。目前开源的组件库有MyFaces,ADF等可以使用,其中有些组件内置AJAX支持。

开发工具中IBM WebSphere Studio,Oracle JDeveloper 10g和FaceIDE等IDE对JSF应用开发提供可视化编辑支持。下面是对JSF自定义组件和JSF+facelet composition组件开发进行比较

JSF自定义组件开发:

JSF自定义组件由java代码和tag库文件组成，开发难度应该与现有I2SS组件开发的难度基本一致,JSF自定义组件通过自定义标记构造页面，在页面上增加组件的数量对性能有较大的影响。

JSF + facelet composition组件开发:

facelet composition组件在个性化、重用方面对JSF提供了很好的补充。通过编写tag库文件，使用facelet可以把多个JSF自定义组件组合成facelet composition组件，或者把几个facelet composition组件组合成新的facelet composition组件,这个过程不需要开发或设计人员编写Java代码。facelet composition组件是live模式运行时生成，从测试结果上看组件数量对性能的影响不大

学习曲线上,开发难度与组件基本一致,只要写过组件或写过servlet+jsp的人,加上适当培训,一周内都可掌握JSF或Tapestry开发

Tapestry

组件和页面的开发过程完全一致，都是由模板、page/component class和specification文件组成。IDE方面目前有开源社区开发的eclipse插件Spindle和Tapestry Palette可用，对开发效率有一定的提升。

3.JSF和Tapestry集群支持方面

JSF

目前在I2SS上做的集群实验是使用apache+jboss来实现，结构是apache做集群前端实现stick session，jboss做应用服务器。

I2SS架构应用程序Session中放入的对象并不能全部串行化，所以在做集群时只能使用粘贴会话方式(stick session)实现,这样容易出现的情况是如果一台机器down掉，这台机器上的所有在线用户都会无法继续当前的会话。如果用户重新发起登录请求，任务会转移到其它正常工作的机器上。如果down掉的机器重新恢复，转移到其它机器上的用户不能重新使用这台新启动的机器，只有新发起的用户请求和在线用户调用session.invalidate()显式退出后，工作才会转移到新启动的机器上，这样负载的均衡时间会比较长。I2SS架构应用程序可以通过更改框架层，将现有放入session中的对象实现串行化，并且将不能串行化的对象放到session以外的地方来实现使用session replication的集群模式。

在JSF上做的集群实验是使用apache+jboss来实现,支持stick session和session replication两种模式。stick session模式的结构和讨论如上述，session replication的结构是apache做集群前端,通过jboss的TreeCache实现session replication。在编写JSF程序时要把放入会话中的backing-beans实现串行化，如果一台机器down掉，在线用户的会话会转移到其它正常工作的机器上，对于用户的感受来说可能是速度变慢，但是不会出现会话断掉的情况。如果down掉的机器重新恢复，TreeCache通过网卡或文件系统完成session replication的过程后，在线用户的任务就可以实现与机器未down时相同的负载均衡状态。如果想减少网卡或文件系统的I/O操作，可以通过集群分区来实现。

Tapestry

Tapestry本身提供两种state持久方式：传统的session方式和client-side方式。状态保存在session中的情况下，实现集群和JSF方式一样，需要session replication。保存在client-side的情况下，有一些局限性，但是可以实现无状态的应用，自动支持集群。

4.对于I2SS组件与JSF组件混合使用的说明

JSF组件应用程序是标准J2EE应用程序，JSF组件对servlet API提供了封装，同时也提供了直接得到servlet上下文的方法，所以I2SS组件与JSF组件的混合使用与现在已经实现的邮件系统中servlet+JSP与I2SS组件的混合使用方法是一样的，都可以用手动创建EbiContext实例的方法来实现。

5.目前JSF标准的进展情况，以及行业的支持情况

JSF 体系结构
JavaServer Faces 的 MVC 实现
JSF 的主要优势之一就是它既是 Java Web 用户界面标准又是严格遵循模型-视图－控制器 (MVC) 设计模式的框架。用户界面代码（视图）与应用程序数据和逻辑（模型）的清晰分离使 JSF 应用程序更易于管理。为了准备提供页面对应用程序数据访问的 JSF 上下文和防止对页面未授权或不正确的访问，所有与应用程序的用户交互均由一个前端“Faces”servlet（控制器）来处理。

到此，关于“Tapestry和JSF的比较”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！