SSH篇（后台）一、SSH概述1.1 SSH的含义当前J2EE企业级应用分为三层：表现层-业务层-数据源层，而SSH代表了每一层的具体实现，它是三种流行的开源框架的缩写，S-Struts,S-Spring,H-Hibernate。

这三者的组合是当前J2EE开发的标准模式，也代表了J2EE正在朝着简化复杂性，轻量化方向发展，最新J2EE 6已证明了这种趋势。

1.2 J2EE开发模式的演变J2EE应用一直采用三层加构，即表现层-业务层-数据源层。

旧石器时代：J2EE应用采用表现层-远程EJB-实体EJB（或JDBC），这是最为正宗也是最复杂的J2EE开发，适用于银行等小部分项目；随后由于微软.NET的兴起以及其对J2EE的挑战，正宗的J2EE出现了一个变种：表现层-本地EJB-Ibatis，在这种模型中业务层选择了本地EJB，同时数据源层也改为Ibatis，这种模式极大的提高性能，华为大部分项目采用这种构架。

在这两种架构中，由于采用了EJB组件模型，从而依赖于EJB容器，而EJB容器以一种全无或全有的方式提供服务，同时业务实现也受制于容器。

这种开发模式导致了以下复杂性：依赖于应用服务器，不可移植，开发困难，无法在容器外测试，部署复杂，效率低下。

新石器时代：在新石器时代依然采用了三层加构，只是抛弃了EJB，而采用了Spring等轻量级容器，同时持久化由全自动的Hibernate承担。

在这种架构中，由于放弃了EJB，放弃了全功能的应用服务器，在节省了软件许可费用的同时也大大提高了软件开发效率。

由于web服务器的可移植也好于应用服务器，从而使得J2EE应用可顺利移植。

1.3 SSH与传统开发的比较从上面所述可以看出传统J2EE开发和SSH开发的不同。

简言之，传统J2EE开发采用EJB组件在限制了业务实现的同时也极其复杂，只适用银行等一部分应用；SSH不强制采用应用服务器，不限制业务实现，透明的持久化从而减化了开发的复杂度，提高了开发效率。

二、Struts-WEB层开发的标准2.1 Struts简介Struts是Apache软件基金会的一个开源项目。

采用Servlet／JSP技术，实现了基于J2EE Web应用的MVC设计模式的应用框架，是MVC经典设计模式中的一个经典产品。

使用标准的JSP以外，还提供了大量的标签库使用，同时也可以与其他表现层组件技术（产品）进行整合。

Struts出现之前J2EE Web层没有统一标准，各个公司都是自有框架，给从业者，企业带来了诸多不便。

Struts采用了经典MVC设计，从而事实上成为WEB层开发的标准2.2 Struts的原理在谈到Struts前，简单讲下MVC设计模式。

MVC即Model-View-Controller的缩写，MVC减弱了业务逻辑接口和数据接口之间的耦合，同时让视图层更富于变化。

MVC的工作原理,如下图1所示：控制器（Controller）-负责转发请求，对请求进行处理。

视图（View）- 界面设计人员进行图形界面设计。

模型（Model）- 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

Struts 是MVC的一种实现，它将Servlet和JSP 标记用作实现的一部分。

Struts继承了MVC 的各项特性，并根据J2EE的特点，做了相应的变化与扩展。

Struts的体系结构与工作原理如下图2所示：从图2中我们可以知道，Struts的体系结构包括模型（Model），视图（View）和控制器（Controller）三部分。

下面让我们从用户发出请示角度来看看struts的体系结构（Model 2）与工作原理：（1）首先，用户（通常通过浏览器，如IE）发出请求，Struts的控制器（Controller Servlet）得到请求。

（2）Struts控制器通过配置文件得到业务逻辑处理Action，并调用Action的处理用户请求。

（3）Action处理业务业务逻辑（可能查找数据库或调用别的系统），处理完成后，填充相关的Model对象，并把控制权返回控制器。

（4）控制器选择相应的视图（视图从模型里取出数据），并返回给用户。

2.3 Struts2简介Struts2提供了对MVC的一个清晰的实现，这一实现包含了很多参与对所以请求进行处理的关键组件，如：拦截器、OGNL表达式语言、堆栈。

下图是Struts2的处理流程。

一个请求在Struts2框架中的处理大概分为以下几个步骤1 客户端初始化一个指向Servlet容器（例如Tomcat）的请求2 这个请求经过一系列的过滤器（Filter）（这些过滤器中有一个叫做ActionContextCleanUp 的可选过滤器，这个过滤器对于Struts2和其他框架的集成很有帮助，例如：SiteMesh Plugin）3 接着FilterDispatcher被调用，FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action4 如果ActionMapper决定需要调用某个Action，FilterDispatcher把请求的处理交给ActionProxy5 ActionProxy通过Configuration Manager询问框架的配置文件，找到需要调用的Action类6 ActionProxy创建一个ActionInvocation的实例。

7 ActionInvocation实例使用命名模式来调用，在调用Action的过程前后，涉及到相关拦截器（Intercepter）的调用。

8 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。

返回结果通常是（但不总是，也可能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。

在表示的过程中可以使用Struts2 框架中继承的标签。

在这个过程中需要涉及到ActionMapper2.4 Struts，Struts2的比较在Action 实现类方面的对比：Struts 1 要求Action 类继承一个抽象基类；Struts 1 的一个具体问题是使用抽象类编程而不是接口。

Struts 2 Action 类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。

Struts2 提供一ActionSupport 基类去实现常用的接口。

即使Action 接口不是必须实现的，只有一个包含execute 方法的POJO 类都可以用作Struts 2 的Action 。

线程模式方面的对比：Struts 1 Action 是单例模式并且必须是线程安全的，因为仅有Action 的一个实例来处理所有的请求。

单例策略限制了Struts 1 Action 能做的事，并且要在开发时特别小心。

Action 资源必须是线程安全的或同步的；Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。

Servlet 依赖方面的对比：Struts 1 Action 依赖于Servlet API，因为Struts 1 Action 的execute 方法中有HttpServletRequest 和HttpServletResponse 方法。

Struts 2 Action 不再依赖于Servlet API，从而允许Action 脱离Web 容器运行，从而降低了测试Action 的难度。

当然，如果Action 需要直接访问HttpServletRequest 和HttpServletResponse 参数，Struts 2 Action 仍然可以访问它们。

但是，大部分时候，Action 都无需直接访问HttpServetRequest 和HttpServletResponse，从而给开发者更多灵活的选择。

可测性方面的对比：测试Struts 1 Action 的一个主要问题是execute 方法依赖于Servlet API，这使得Action 的测试要依赖于Web 容器。

为了脱离Web 容器测试Struts1 的Action，必须借助于第三方扩展：Struts TestCase，该扩展下包含了系列的Mock 对象(模拟了HttpServetRequest 和HttpServletResponse 对象），从而可以脱离Web 容器测试Struts 1 的Action 类。

Struts 2 Action 可以通过初始化、设置属性、调用方法来测试。

封装请求参数的对比：Struts 1 使用ActionForm 对象封装用户的请求参数，所有的ActionForm 必须继承一个基类：ActionForm。

普通的JavaBean 不能用作ActionForm，因此，开发者必须创建大量的ActionForm 类封装用户请求参数。

虽然Struts 1 提供了动态ActionForm来简化ActionForm的开发，但依然需要在配置文件中定义ActionForm；Struts2 直接使用Action 属性来封装用户请求属性，避免了开发者需要大量开发ActionForm 类的烦琐，实际上，这些属性还可以是包含子属性的Ric对象类型。

如果开发者依然怀念Struts 1 ActionForm 的模式，Struts2 提供ModelDriven 模式，可以让开发者使用单独的Model 对象来封装用户请求参数，但该Model 对象无需继承任何Struts 2 基类，是一个POJO，从而降低了代码污染。

表达式语言方面的对比：Struts1 整合了JSTL，因此可以使用JSTL 表达式语言。

这种表达式语言有基本对象图遍历，但在对集合和索引属性的支持上则功能不强；Struts 2 可以使用JSTL，但它整合了一种更强大和灵活的表达式语言：OGNL（Object Graph Notation Language），因此，Struts 2 下的表达式语言功能更加强大。

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

类型转换的对比：Struts1 ActionForm 属性通常都是String 类型。

Struts 1 使用commons-Beanutils 进行类型转换，每个类一个转换器，转换器是不可配置的；Struts 2 使用OGNL 进行类型转换，支持基本数据类型和常用对象之间的转换。

数据校验的对比：Struts1 支持在ActionForm 重写validate 方法中手动校验，或者通过整合Commons-validator 框架来完成数据校验。