Struts与几种MVC框架的比较

注:本文内容为网上收集 整理!

(一)Struts与WebWork:

特 征<o:p></o:p>	Struts1.1 <o:p></o:p>	WebWork2 <o:p></o:p>
Action类<o:p></o:p>	在Struts里面，每一个Action类必需要继承一个抽象的类org.apache.struts.action.Action。这个在Java编程中会引来一些问题，就是关于多种继承的问题。 <o:p></o:p>	WebWork的Action类仅需要实现接口com.opensymphony.xwork.Action，也可以实现其它的接口来实现更多的功能，譬如：validate（验证），localware(国际化)等。当然，它也提供了一个类ActionSupport集成了上面的所有功能，我们在开发中可以根据需要选择。 <o:p></o:p>
线程模型<o:p></o:p>	Struts 的Action必需是thread－safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。 <o:p></o:p>	在WebWork中，每个请求对应一个Action，因此没有线程的安全问题。实际上Servlet容器对每个请求也产生多个对象，它也没有证明对性能和垃圾回收产生太多的影响。 <o:p></o:p>
Servlet的依赖<o:p></o:p>	Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。 <o:p></o:p>	WebWork的Action不用依赖Web层和其它的容器。它可以通过ActionContext，直接去访问Request和Response，但这个是可选的，只有在必需的请求下使用。 <o:p></o:p>
测试<o:p></o:p>	Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。<o:p></o:p>	Webwork的action能够通过赋予一定的属性，就可以执行单元测试。同时也可以使用一个mock的实例去测试，而不是通过启动web容器来进行测试。 <o:p></o:p>
FormBean<o:p></o:p>	Struts要求有FormBean对应每一个表单，而且FormBean必需继承抽象类ActionForm。而使用DynaBeans实际上没有太大的意义。不能够很好的处理现有的模型。 <o:p></o:p>	Webwork 能够动态的收集web的数据然后再赋值给bean。它也可以使用FormBean的形式，FormBean可以是普通的DTO和域对象，它不用重新根据域对象来生成新的FormBean，也不需继承抽象类ActionForm。 <o:p></o:p>
前端表达式语言<o:p></o:p>	Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。 <o:p></o:p>	WebWork的表达式语言使用了功能强大的OGNL。它使用OGNL建立一个OgnlValueStack来搜索数据。Webwork前端也可以使用JSTL，但它同时支持：velocity、freemaker、jspparer、xml。 <o:p></o:p>
类型的转换<o:p></o:p>	Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。 <o:p></o:p>	WebWork使用OGNL进行类型转化，提供了所有基本类型的转化功能。类型转化可以直接对一个Class进行（Class级别）转化，也可以对Class的字段进行类型转化。它使用拦截器可以很容易的将类型转化的错误信息返回给用户，而且错误信息可以对应到一个相应的字段。 <o:p></o:p>
对Action 执行前和后的处理<o:p></o:p>	Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。 <o:p></o:p>	Webwork2 允许您处理Action可以通过拦截器，就是在每一个Action处理前或者后进行其它操作。它的拦截器可以在配置文件中动态添加，这样Action和拦截器之间完全解藕，更好的实现了组件化。 <o:p></o:p>
验证处理<o:p></o:p>	Struts的验证是调用FormBean的validator()方法，其实就是对FormBean的验证。它一般使用框架Commons Validation进行数据验证处理。它使用了一个全局的配置文件validation.xml定义了FormBean的验证信息。Struts的FormBean属性都被认为是String类型，所以它在验证时也需要额外的类型转化。 集成Validator验证框架.	WebWork使用Xwork的验证框架进行验证处理，它可以通过配置拦截器来激活。它可以为每个需要验证的Class指定一个xml验证文件，也可以为一个Class在不同的情况指定不同的xml验证文件。WebWork证可以给每个Action类指定对应的验证文件，也可以给Action的字段去指定验证文件。通过拦截器来组装Action和其验证文件，使它们之间完全解藕。 <o:p></o:p>
对Action执行的控制<o:p></o:p>	Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。 <o:p></o:p>	在这个方面，WebWork的拦截器栈提供了强大的功能。Action的所有切面功能都有拦截器来实现（比如：取得request请求参数、验证处理等），这样你就可以用拦截器栈来组织拦截器的执行顺序。例如：你需要在使用request请求参数来设置Action属性之前，使用IoC框架设置Action的属性，反之已然。这时，你就可以为package或Action指定一个拦截器栈来实现。<o:p></o:p>

 

(二)Struts JSF Tapestry:

	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 接口

(三)几种框架的优缺点:
      

框架名称<o:p></o:p>	优点<o:p></o:p>	缺点<o:p></o:p>
Struts<o:p></o:p>	业界“标准”（很多成功案例），学习资源丰富，上手很容易<o:p></o:p>	ActionForm使用不便、无法进行单元测试（StrutsTestCase只能用于集成），标签不好用<o:p></o:p>
Spring MVC<o:p></o:p>	易于同其它View框架（Titles等）无缝集成，采用IOC便于测试<o:p></o:p>	使用人数少、缺乏很好的表单标签、控制器过于灵活，缺少一个公用控制器<o:p></o:p>
JSF<o:p></o:p>	J2EE标准、易于开发、丰富的导航框架<o:p></o:p>	JSP标签差、技术不成熟<o:p></o:p>
WebWork<o:p></o:p>	结构简单易于扩展、标签库易于定制、拦截器非常出色<o:p></o:p>	文档示例很少、客户端验证技术不成熟<o:p></o:p>
Tapestry<o:p></o:p>	很好用只要你能学会、Html模板、Healthy and smart user community<o:p></o:p>	文档太概念，不利于编程，学习曲线太陡，不能测试<o:p></o:p>