JSF(Java Server Faces)是目前sun指定为view层标准的表示层技术。当前的版本为1.1。 Struts是一个使用较为广泛的开源表mvc框架。当前在国内使用的人数众多,目前的版本也是1.1。
笔者正在为一个项目框架作技术选型,所以先后研究了这两种技术。本人打算就目前所掌握的知识对这两种技术作一对比和分析。由于是初学,可能有不正确或者不完整的地方,希望大家能积极的讨论,指正。
据说JSF的主要负责人就是struts的主要作者,所以二者的相似点还是有很多的。
- 都采用taglib来处理表示层:在jsp页面中,二者都是采用一套标记库来处理页面的表示和model层的交互。
- 二者都采用了bean来作为和jsp页面对应的model层。该model层保存了jsp页面上的数据,同时可以作一些验证工作,在struts中就是FormBean,在JSF中就是back bean。
- 都采用bean作为控制层,Struts中采用ActionBean来处理业务逻辑,对于简单的应用可以直接在ActionBean中 编写业务逻辑代码,也可以调用另外的bean或者EJB来处理业务逻辑;对于JSF则采用backing bean来处理业务逻辑,同样,backing bean也可以直接编写业务逻辑或者调用其他的bean来处理业务逻辑。
- 都采用xml配置文件来处理bean的配置,页面导航等问题,增加了系统的灵活性。
- 都采用资源文件来处理国际化和本地化的问题。
然而,二者的不同点也很多,下面分别说明:
- 首先二者的侧重点不同,Struts侧重于控制层,侧重于如何分派和处理用户的请求,所以表示层的taglib功能不够强大。而JSF则侧重于表 示层,实现了大量的标准组件,允许开发人员对表示层有更多的控制权,同时JSF实现了一个开放的架构,允许开发人员创建自己的组件,或者在现有的组件上继 承,开发功能更强大的组件。本人认为这是JSF最大的一个特色。(有点类似于vcl和.net组件)
- 和jsp对应的model层,在Struts中采用FormBean来保存用户输入的数据,基本上一般字段的类型都是String。而 且可以进行简单的验证,当然如果采用动态的FormBean就不能在FormBean中进行验证了。在Struts中,jsp和FormBean是紧密结 合在一起的,只要写一个jsp就必须对应一个FormBean,同时jsp上的每个组件都对应FormBean中相同名字的字段。本人认为这里不太灵活, 比如,开发页面的时候就必须考虑后台的FormBean的实现,但此时如果该页面没有FormBean的化则程序运行时会出错。在JSF中,JSP页面中 的组件通过value属性和backing bean的字段关联,这样就有比较大的灵活性,页面上的每个组件可以对应相同的backing bean,也可以对应不同的backing bean(当然本人认为在一般的应用中,一个页面上的组件还是都对应到一个backing bean较好),而且在设计页面的时候可以不考虑backing bean如何设计,可以在设计完页面之后再考虑backing bean的实现问题。
- 关于数据验证,Struts可以采用在FormBean中的验证函数中进行验证,也可以使用validator进行验证(关于这种验证 方法,本人没有测试过,不知效果如何,希望有经验的朋友指教!)。在JSF中,提供了一些标准的validator。可以对输入的数据做一些简单的验证, 例如验证数值数据的范围,字段是否必填等。但其验证的反馈信息为英文。如果该信息不能自定义的化,那么针对国内的应用就不太适合了,目前本人还没有找到该 反馈信息是否能够自定义的办法。另外对于input类型的组件可以通过validator属性关联到backing bean的一个验证方法上。在事件处理方法中进行验证也是一个办法。
在JSF中还有一个问题就是在JSF生成的页面中,组件的Id命名比较怪 异,所有的组件的id都类似于“form:compnentid”即form的名称+“:” +组件的id。这样通过javascript访问组件就不是很方便,通过form.id形式好像不能访问到组件。不知道各位有没有好的解决方案。
(Above content is from http://blog.csdn.net/xu_xinyu/archive/2004/09/06/95786.aspx)
-
控制层:Struts中通过form的action来提交请求,通过ActionServlet来分发请求,最后由ActionBean来处理请 求,在Action中实现业务逻辑或者调用其他的业务逻辑bean来完成用户的请求并返回客户端。在这里,一个form只有一个action,即一个页面 只能提交到一个action Bean。对于页面上有多个按钮都需要提交的情况就需要使用一些变通的方法了。和传统的web开发的模式比较接近。
对 于JSF,采用了事件模式来处理用户提交的请求。JSF实现了事件监听器来监测事件,例如当用户单击了一个按钮就会触发一个按钮单击事件,还有 valuechange事件监听器来监测数值改变的事件等。例如在页面中通过通过CommandButton按钮的action属性来关联到 backing bean的方法来执行相应的操作。 每个不同的按钮都可以关联不同的方法,当然也可以关联相同的方法(这样就和Action Bean非常类似了)。这中开发模式比较接近于传统的c/s模式或者Asp.net的开发模式。对于那些从c/s架构程序或者Asp.net架构转过来的 开发者来说,这种方式可能更自然一些。
在JSF的一些简单的示例程序中,通常把和jsp对应的model层和jsp所提交的action放在同 一个backing bean中,即业务逻辑和业务逻辑所处理的数据在同一个bean中。本人认为,这样的结构只能用在简单的应用中,对于企业级的开发并不适合。应该将页面所 关联的数据和页面所做的action分开,这样的结构更好一些,比较类似于struts的结构。
JSF的backing bean中的方法访问session,request等没有struts中的直观。笔者找了很多例子才知道如何访问session中的数据。 - 页面的导航:关于页面的导航,struts和JSF比较类似。都是在xml的配置文件中配置导航规则。每个要跳转的页面都有一个别名, 在程序中通过别名进行跳转。另外Struts中的跳转是在ActionBean中发生,execute方法最后返回一个actionForward来进行 跳转。而JSF则在事件处理方法中最后返回一个字符串,由系统在xml文件中匹配自动进行跳转。在JSF中也可以通过在JSP页面的 CommandButton的action属性中直接填写跳转的别名直接跳转,而不必经过事件处理方法的处理。
- 资源文件的管理:Struts和JSF对于资源文件的管理比较类似,Struts中在struts-config.xml中对资源文件 进行配置,实现整个程序的统一管理。而对于JSF则可以在每个JSP页面中分别定义资源文件,然后通过资源文件的别名来访问资源文件中的内容。两者的格式 也不相同,在Struts中,格式为: grade1.grade2.grade3 = your information,通过“.”来表示级别。而在JSF中则必须通过下划线来表示级别,例如grade1_grade2_grade3= your information。本人认为还是struts的方案更直观一些。另外在Struts的资源文件中可以定义信息的显示格式,例 如:error.header,error.footer。而JSF中如何定义还不太清楚,或者可以通过定义Messages标记的属性来定义。
(Above content is from http://blog.csdn.net/xu_xinyu/archive/2004/09/06/95897.aspx)
Struts 有以下优点:
- Struts 是一个成熟的、被证实了的框架。它已经使用了几年,且被成功部署到许多项目中。WebSphere Application Server 管理控制台就是一个 Struts 应用程序。
- Struts 使用 Front Controller 和 Command 模式,可以处理复杂的控制器逻辑。
- 除了核心的控制器功能以外,它还有很多其他的优点,比如使用 Tiles 布局、说明性(declarative)异常处理以及国际化。
以下是其缺点:
- Struts 是非常以 JSP 为中心的,必须使用其他框架来适应其他视图技术。
- 尽管 Struts 有丰富的标记库,但是它只能帮助进行控制器方面的开发,当您处理关于页面的组件时,它没有任何意义。因此,从视图的角度来看,它没有提供好的工具。
- Struts 需要关于 Java™ 的知识。其目的是帮助 Java 开发人员,而不是隐藏 Java。它在对 Web 开发人员隐藏 Java 语言的细节这一方面做的并不好。
- ActionForms 被程式化的与 Struts 框架链接。因此,为了降低模型的耦合度,您需要编写传送代码或者在输入时使用工具将数据从 Action Forms 移动到 Model。
JSF 从包括 Struts 的少数框架发展而来。Struts 的创建者,Craig McClanahan,即是 JSF 规范的领导人之一。因此,能看到 Struts 和 JSF 之间的一些相似之处,这并不是偶然的。JSF 的主要目的之一就是使得 J2EE Web 应用程序在 RAD 工具下易于开发。同样地,它也引入了丰富的组件模型。JSF 有如下优点:
- JSF 是一个来自 Sun® 的规范,将会被包括在 J2EE 规范的未来版本之中。各主要供应商都保证对 JSF 提供强力支持。
- JSF 使用 Page Controller Pattern,因此会对页面密集型应用程序有帮助。相应组件会对来自页面上组件的事件作出响应。
- JSF 有一个明确定义的请求生命周期,保证了在不同级别上的可插入性(plugability)。
- 可插入性的一个有力的例子是构建您自己的 render 工具包。将框架中的呈现(rendering)部分和控制器部分分离的能力实现了良好的可扩展性。组件供应商可以编写他们自己的工具包以处理不同的标记语 言,如 XML 或 WML。另外,render 工具包也不依赖于 JSP。
- 因为 JSF 有一个丰富的组件模型,所以它支持 RAD 类型的开发。现在我可以使用拖放技术来构建我的 Web 页面。此外,JSF 提供在不打破层次布局的条件下,将可视组件同后台模型组件连接起来的途径。
JSF 有以下缺点:
- JSF 仍是相当新的并处于发展过程中。要看到成功的部署和广泛的应用还需要一段时间。另外,组件供应商可能并不能做您想让他们完成的所有事情。
- 手工方式的 JSF 并不比 Struts 简单。它的目标更倾向于 RAD。那些喜欢手工开发的人(例如,那些不喜欢 IDE 的 vi 类型的人)可能会发现 Struts 更容易开发。
- Struts 导航可能会更加灵活一些,但同时也导致控制器逻辑更加复杂。
(Above content is from http://blog.csdn.net/naxin/archive/2004/08/30/88423.aspx)