表示层框架Struts/Tapestry/JSF较量
当前位置:以往代写 > JAVA 教程 >表示层框架Struts/Tapestry/JSF较量
2019-06-14

表示层框架Struts/Tapestry/JSF较量

表示层框架Struts/Tapestry/JSF较量

副标题#e#

Struts/Tapestry/JSF是今朝J2EE表示层新老组合的框架技能。从降生时间上 看,Struts应该较量早,利用得很是遍及,Tapestry 3.0逐渐引起遍及的重视 ,合法Tapestry即将大显身手时期,SUN推出JSF尺度技能,固然JSF一开始推出 尚不成熟,留出了一段空缺期,可是跟着JSF1.1尺度推出,JSF开始正面出击, 粉面谨慎登场了。

其实,JSF和Tapestry也并不是那种头见面的沟通竞 争性技能,两者照旧各有偏重点的,不外较量细微,可是这种细微点在实现一个 大工程时大概带来差异的感觉和变革。

首先,我们从一个高度来抽象一下表 现层框架应有的技能架构,下图可以说所有表示层框架技能都必需实现的成果架 构图:

虽然,我们不必空话罗嗦MVC模式,MVC模式是基准模式,此刻框架技 术已经不必再拼是否是MVC模式了。在上图MVC模式基本上,一个表示层框架无外 乎要实现图中的三个成果:

1.在当前页面可以或许显示一个组件工具的内容;而 不是象纯JSP那样,需要在Jsp页面写入“挪用工具要领”的Java代码 。

2.当用户按下页面的提交按扭或链接后,事件产生,这时应该触发处事器 端并将当前页面的参数提交给处事器。这种机制表示在Form表单提交和有参数的 链接<a href=""></a>

3.从一个页面视图直接跳转 到别的一个页面视图,纯真的导航浸染。

我们通过下表来较量这 三种框架 在实现上图各个成果时技能细节,从而得出他们的异同点和侧重点。

Struts  Tapestry3.0 JSF

在View显示的组件要求 组件必需担任 ActionForm

分显式挪用和隐式挪用

组件必需担任BaseComponent 普通 POJO

无需担任

Managed Bean

组件在View显示粒度 View页面只 能显示与表单对应的ActionForm,设置中Action ActionForm 页面一般只能 1:1:1干系。可将组件嵌入页面任何一行,对利用组件数量无限制。同 Tapestry

页面分区tiles 利用Tiles标签库实现,需要别的tiles- def.xml设置文件 组件有本身的视图页面,通过挪用组件即直接实现多个页面 组合。强大自然的页面组合是其特点。通过组件+标签库实现Subview,但如需重 用Layout,还要团结Tiles.

页面跳转 利用标签库html:link中写明目 标URL,URL名称需要比较设置文件的path定名,与组件Action耦合。URL名称是目 标的组件名称,不涉及URL和路径等操纵,利便稳固。雷同Struts,也需要在配 置文件中查找,与组件疏散。

参数通报 利用html:link时通报参数超 过一个以上处理惩罚贫苦。直接挪用组件,直接赋予参数,没有参数个数限制 参数 疏散通报给组件

事件触发 通过表单提交submit激活,不能细化到表 单里字段。可以或许给于表单每个字段贴一个事件,事件组件必需实现PageListener 接口 同Tapestry,事件组件必需实习ActionListener 接口


#p#副标题#e#

Struts组件编程模子

Struts实现组件编程时有一些巨大 :常常为一个页面中需要引入多个组件而头疼,因为Struts中无法直接引入多个 组件,必需绕一些圈子:

一般分两种环境:假如同一个Action就可以搪塞这些 组件,那么在这种环境下有两个步伐:

1.将这多个组件装入一个ActionForm 中,如利用MapForm等机制;

2.手工将多个组件装入request/session等scope 中,然后按照其名称在jsp中得到。

这两个要领都有缺点: 第一种步伐常常 一个ActionForm弄得涣然一新,酿成一个大杂烩,违反了OO分配封装的原则;第 2种步伐其实又回到jsp编程;

第二种环境,假如这些组件必需有预先由差异 的Action来处理惩罚,每个组件必需颠末Action –>ActionForm流程,在这种情 况下有两种步伐:

1.利用Tiles, 差异流程输出到同一个页面的差异区域。 是一种并行处理惩罚方法。

2. 对多个流程首尾相连,第一Action forward功效 是第二个Action,最后输出一个Jsp,在这个jsp中就可以利用前面多个流程的多 个ActionForm了,这属于串行方法。

Struts组件模子缺点

Struts组件编程 必需限定在Action/ActionForm/JSP这三个框框中做文章,难度相比拟力大,而 Tapestry/JSF则没有太多这些技能框框限制,两者在组件编程方面更让编程者自 由一些,利便一些,这也是组件型框架的优势吧。

Struts标签库

在Struts 中,常常需要利用标签库来显示组件ActionForm中内容,这就涉及到一个团结的 问题,标签库是别人写的,参考Struts的标签库用法,而组件是本身的,难度和 贫苦就表此刻这个团结点上。

JSF根基思路和Struts差不多,只不外换了差异 标签库,也需要标签库+组件的团结思考,不外因为组件这里是通用组件,没有 什么限制,所以这样比Struts要轻松一些。

#p#分页标题#e#

Tapestry利用了组件库观念替代 了标签库,没有标签库观念,这样就没有标签库和本身的组件需要团结的问题, 都是组件的利用,组件中分Tapestry尺度组件和本身界说的组件,这也是打仗了 Jsp体系的人进修Tapestry面对的一个思路转换。

详细以页面跳转为例子,页 面跳转是靠链接<a href="方针"></a> 实现,链接是 页面常常利用的元素。

Struts提供的html:link在频繁利用就出格不利便,尤 其在通报多个参数时:个中html:link的page值,是跳转对方页面或Action的 path,这个path一般需要到struts-config.xml查找Action的相应path,一旦设置 文件path值修改,涉及到这个所有相关页面都要修改。

JSF将链接观念分别两 个方面:导航性质和事件激活,在导航方面照旧需要到设置faces-config查询 Navigation的from-outcome的值。

由于Tapestry没有标签库观念,只有组件 或页面两个观念,因此,链接跳转方针要么是组件,要么是页面,简捷简朴,它 没有多余的path观念,就是组件名,也就是工具名称,组件名称和path名称合二 为一。

总结

JSF在很洪流平上雷同Struts,而不是雷同Tapestry,可以说 是一种Struts 2.0,都是采纳标签库+组件的形式,只是JSF的组件观念没有象 Struts那样必需担任ActionForm的限制;JSF在事件粒度上要细腻,不象Struts 那样,一个表单一个事件,JSF可以细化到表单中的每个字段上。

JSF只有在 组件和事件机制这个观念上雷同Tapestry,可是不似Tapestry那样是一个完全组 件的框架,所以,假如你做一个对页面要求机动度相当高的系统,选用Tapestry 是第一思量。

Struts/JSF则适合在一般的数据页面录入的系统中,对付 Struts和JSF的选用,我今朝小我私家概念是:假如你是一个新的系统,可以直接从 JSF开始;假如你已经利用Struts,不必转换,假如需要切换,可以将JSF和 Tapestry一起思量。

别的,JSF/Tapestry不可是支持Html,也支持多种客户 端语言如WML或XUI等。

这三者之间干系:假如说Struts是左派;那Tapestry 则是右派;而JSF则是中间派,中庸主义是SUN同盟的一贯计策。

虽然,你也 可以颁发你在实践中这三者任何一个的利用感觉,以使得厥后者有一个较量。

    关键字:

在线提交作业