作者：game.19xz
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形式好像不能访问到组件。不知道各位有没有好的解决方案。
控制层：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标记的属性来定义。
