Struts2入门--Struts2的背景以及与Struts1的对比

本文仅从Struts 2 的发展上做一个简单的介绍，不做具体技术和使用上的介绍。

1.Struts2的简史：
这要从Servlet说起，Servlet是Java在web领域开创性的尝试，至今Servlet在Web领域的重要性也是不言而喻的。但是最初仅仅依靠遵循了HTTP协议的Servlet这种在Java代码中生成HTML代码的方式，对于维护来说简直就是噩梦。问题的出现必然要去解决，于是出现了JSP技术。
JSP和Servlet正好相反，他是在HTML代码中插入Java代码来实现业务逻辑。随着JSP规范的逐步完善，解决了早期JSP的一系列问题，使得JSP成为Web开发中的一把利器。否定之否定，旧的问题解决后又产生了新的问题。在纯JSP页面中，业务逻辑要完全的依靠其中的Java代码，并且大量的<%
%>,{}以及Java代码交叉起来使得整个页面的源代码眼花缭乱。新的问题的出现又导致了另一种Web架构设计思想的出现，那就是分层。

出现的模式有Model1 和
Model2等，Model1模式只适用于业务逻辑简单的应用。Model2模式就是模型-视图-控制器模式，还有一个叫法就是MVC模式。模型的具体介绍在次不做讨论。随后出现的Struts1.x、Spring、Hibernate、WebWork等开源框架，很好的支持了MVC模式的思想，这些框架的出现给Web开发带来了极大的便捷。

Struts项目组看中了WebWork项目的技术，而WebWork项目组看中了Struts的市场以及人气。这时两个项目组有了合作的意向，当两个项目组发现彼此在技术和开发人员的共同之处后，就在WebWork的技术基础上进行了合作，于是就有了Struts2。使用过Struts1.x的开发人员就会知道为什么Struts1和Struts2有太多的不同，关键就是Struts2大量吸收了WebWork的技术。网上有一段介绍WebWork的简语"当我们说起WebWork的时候，我们实际上说的是两个项目--XWork和WebWork。XWork是一个通用的命令框架，它提供了很多核心的功能，例如actions，验证和拦截器，它可以完全独立于执行上下文运行，并提供了一个内部的依赖注入机制，用来做配置和工厂实现的管理而WebWork则是一个完全独立的上下文。它用Web应用中运行所需的上下文把XWork包装起来，并提供了可以简化Web开发的特定实现。"

2.基于Action的框架：

基于Action的框架把Servlet和JSP的概念合并到了一起。它的想法是把对当前用户所见的页面请求的处理动作，分拆成处理逻辑和表现逻辑，让它们各司其职。这就是MVC框架的基本原理了，Struts2就是基于Action框架的典型代表。在这个模式中，Servlet是控制器，集中处理所有的客户端页面请求。它把所请求的URL与被称为Action的工作单元映射到一起。Action的工作就是通过访问HTTP会话、HTTP请求和表单参数等调用业务逻辑，最后把响应映射到以POJO（plain
old java
object）形式存在的模型上，来完成特定的功能。最后，Action返回的结果会通过配置文件映射到JSP页面上，JSP会渲染视图并显示给用户。

3.基于组件的框架：

当Web应用变得更加复杂的时候，人们便意识到一个页面已经不再是一个独立的逻辑了--一个页面上会存在多个表单，有内容更新的链接，还有其他很多自定义的Widget--而这些都需要进行逻辑处理来完成各自的任务。出于解决这种复杂度的需要，基于组件的框架开始流行起来。它们在用户界面组件和表示这些组件的类之间提供了一层紧密的连接，它们是事件驱动型的，并且比起基于Action的框架而言，更具有面向对象的特征。一个组件可以是一个HTML输入框，一个HTML表单，框架所提供的或是开发人员创建的Widget。像提交表单或者是点击链接这样的事件，都与代表组件的类的方法或者是特定的监听类，有着一对一的映射关系。基于组件的框架还有一个好处，那就是你可以在多个Web应用之间重用组件。JSF，Wicket
和 Tapestry等都是基于组件的框架。

4.Struts2与Struts1的对比：

在Action实现类方面的对比：S1要求Action类继承一个抽象基类；S1的一个具体问题就是使用抽象类编程而不是接口。S2的Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制服务成为可能。S2提供了一个ActionSupport基类去实现常用的接口。我们通常的做法就是继承ActionSupport类，然后改写父类的execute方法去实现具体的业务逻辑。

线程模式方面的对比：S1 Action是单例模式并且必须是线程安全的，因为仅有Action
的一个实例来处理所有的请求。单例策略限制了Action所能做的事，并且在开打时要特别小心。S2 Action为每一个请求产生一个实例，因此没有线程安全问题。

Servlet依赖方面的对比：S1 Action依赖于Servlet API，因为S1
Action的execute方法中有HttpServletReques和HttpServletResponse方法。S2 Action不再依赖于Servlet
API，从而允许Action脱离Web容器运行。

封装请求参数的对比：S1使用ActionForm对象封装用户的请求参数，所有的ActionForm都必须继承一个基类：ActionForm。不同的JavaBean不能应作ActionForm，因才必须创建大量的ActionForm去封装用户的请求参数。S2直接使用Action在其中封装用户请求参数。

表达式语言方面的对比：S1整合了JSTL，因此可以使用JSTL表达式语言。这种表达式有基本的对象图遍历，但在对集合和索引属性的支持上则功能不强。S2
不仅可以使用JSTL，而且还整合课一种更加强大和灵活的表达式语言：OGNL(Object Graph Notation Language)。

绑定值到视图的对比：S1使用标准JSP机制把对象绑定到视图页面；S2使用ValueStack技术，使标签库能够访问值，而不需要把对象和视图页面绑定在一起。

数据校验的对比：S1支持在ActionForm中重写validate方法手动校验，或者通过整合commons
validator框架来完成数据校验。S2支持通过重写validate方法进行校验，也支持整合Xwork校验框架进行检验。

其他方面的对比