SSH（Struts2+Spring+Hibernate）是最为 Java 业界熟知的 Java EE Web 组件层的开发技术。很多人提起 Java EE，甚至都会将其误认为就是 SSH。无论是书籍还是电子教程，大部分都已经千篇一律，讲解各种标签、配置的用法。许多人包括笔者在内，第一次使用 SSH 的时候，按照教程的介绍进行开发。繁琐的配置，重复的修改配置，不断定义的参数转换器，真的让笔者苦不堪言。本文对 SSH 的开发模式尝试了重新定义，按照规约优于配置的原则，利用 Java 反射、注解等技术，设计了新的一套 SSH 开发框架，应用该框架，可以大大提高开发效率，笔者多次将该开发框架应用在各种小型 SSH Web 应用系统之中，屡试不爽。
阅读文章之前，读者需要对 SSH 的结合开发有一些了解，最好是有实践的经验，特别是对 Struts2 需要较为了解，掌握 Struts2 自定义拦截器、自定义验证器等的开发。另外，读者还需要掌握一些前提技术，包括 Java 反射、Java 注解、理解事务隔离级别等。
文章首先进行框架的总体介绍，然后分点介绍各个部分的详细设计。另外，文章还将列举该框架中采用的技术特点及其相应目的，希望读者可以从中获益。
文章之所以说框架是通用的，因为它的思想适应任何的业务需求。按照文章介绍，按照介绍的框架搭建完代码架构后，可以屏蔽许多技术细节，让开发人员专注于业务逻辑的实现，这些繁琐的技术细节包括技术配置、权限控制、页面跳转、错误处理等等。框架大致的风格如图 1 所示，总体来说，该框架遵守了“规约优于配置”的原则。
上图中，系统只有一个 action 配置。每个业务操作，不再对应一个 ActionSupport 子类，而是对应一个 ActionSupport 子类的类方法，利用 Struts2 的动态方法特性，使得业务方法摆脱了繁琐的配置，方便的增加和删除。全面的 result 配置，解决了各种页面跳转的问题。Action 方法的起名，遵守了权限与业务模型规约，让模型选择与权限控制交给框架来实现，同时访问的操作名就是【方法名】 .action。下面，将一一对框架的各部分进行讲解。
该框架中，我们建议只定义少量的类继承于 ActionSupport，这样可以使得 struts.xml 的配置尽量减少，甚至只进行少量配置，而不用随着业务的增加而修改配置。清单 1 是笔者为一个教师考勤系统定义的 Action 配置。
<action name="*" method="{1}" class="Main">
<interceptor-ref name="fileUpload">
<param name="maximumSize">4073741824</param>
</interceptor-ref>
<interceptor-ref name="myInterceptorStack"></interceptor-ref>
<result name="input">/noDir/error.jsp</result>
<result type="json" name="success"></result>
<result name="errorJson" type="json"></result>
<result type="json" name="error"></result>
<result type="stream" name="stream">
<param name="contentType">${contentType}</param>
<param name="contentDisposition">fileName="${inputFileName}"</param>
<param name="inputName">inputStream</param>
</result>
<result name="dynamic">/${url}</result>
<result name="otherAction" type="redirectAction">/${url}</result>
<result name="red" type="redirect">/${url}</result>
</action>
清单 1 定义了很多规则。首先，该配置使用了动态方法调用技术，这可以使得许多的 Action 方法可以声明到一个类里，不用重复定义 Action 类，同时对业务的增加和删除可以简约到对 Action 类里方法增加和删除，增加的 Action 方法不需进行其他配置，如果业务被删除，则只需要将方法注释或者删除，非常方便。第二，配置的 package 继承于 json-default，也就是说这个包里的 action 是支持 Ajax 调用的，默认的，如果返回 ERROR、SUCCESS，则会将 Action 序列化为 JSON 返回到客户端。我们定义了各种的跳转类型，包括重定向到页面（具体的页面由 Action 里的 url 指定）、重定向到 Action、重定向到错误页面、流类型的返回等等，这为我们动态的选择返回结果数据提供了方便。那么使用上述的配置，对我们开发有什么好处呢？假设有一个新的业务，我们只需要在 Action 添加新的方法，如清单 2 所示。
public String business() throws Exception
{
…business process…
if (has error)
{
addFieldError(“error message”) return INPUT;
} else {
//url是action中定义的一个String变量，指定跳转地址
url = “business.jsp”; return “dynamic”;
}
}
调用这个新的业务方法，只需要调用这个链接：http://{host}:{port}/{webapp}/business.action。正如我们看到的，定义了新的业务逻辑方法，我们没有修改或添加任何配置，因为我们的配置是完整的，考虑到了各种跳转、错误情况，同时动态方法调用特性，让我们可以动态的指定业务方法。如果我们对清单 2 中的跳转代码进行抽取，清单 2 会更加简单。如清单 3 所示。
public String business() throws Exception
{
…business process…
if (has error)
{
return redirectToErrorPage("error message")
} else {
return redirectToPage("business.jsp");
}
}
上面的清单中，我们抽取了 redirectToErrorPage 和 redirectToPage 方法，这样就可以使得其他的业务方法可以重用这些跳转方法，整个业务过程变得清晰易懂。类似的我们还可以抽取出 redirectToAction（跳转到另一个业务方法）、redirectStream（流类型的跳转）、redirectToAnotherPage（用于重定向的跳转）、redirectToJson（Ajax 的跳转）等等。这样这些公共方法就可以让其他的开发人员一起使用。程序员可以从跳转、错误提示、重复配置 Action 的痛苦中解救出来，专注于编写业务逻辑。
有了上面的配置，我们还不能做到完全脱离配置。比如，我们定义了一个 Action 类继承于 ActionSupport，我们知道使用 ModelDriven 可以将用户上传的数据封装到一个业务 Bean 里，而不用直接在 Action 里声明变量，这很重要。我相信有很多读者遇到过这个问题。当业务 Bean 不同时，也就是需要用户上传的数据不同时，我们就要随之添加新的 Action，这直接导致修改 struts.xml 的配置，然后还要修改 applicationContext.xml 的事务配置、Bean 的配置，哪天我们不要这个业务了，又要重复的修改删除配置，笔者开始时为此事近乎抓狂，为什么我们不能只定义一个 Action，而 ModelDriven 的模型动态改变呢？
仔细考虑 Struts2 的机制，Struts2 将客户端的参数装配到 ModelDriven 的模型里，是通过“装配拦截器”装配的。只要我们在装配拦截器执行前，改变 ModelDriven 里的模型对象就行了。这就需要我们自定义一个拦截器，struts2 提供了这个机制。在自定义的拦截器里，我们根据用户调用的 Action 方法，新建一个模型，并且将模型设置到 Action 中，这样模型就可以是动态的了，记住，这个拦截器需要放在 defaultStack 的前面。
同样，新的问题是如何根据 Action 方法动态的选择业务模型呢？难道重复的写 if 方法吗？当然不能这样，动态的模型，就应该来自于动态的方法。因此定义的 action 方法需要有规约，笔者在自己的程序中，是这样定义规约的。Action 方法是这样组成：_$_，使用美元符隔开（美元符是 Java 方法合法的标识符），前部分是操作名，可以任意取，后部分是业务模型的类名。同时，所有的业务模型，都放到指定的一个包里，假设该包名为 com.dw.business。那么在自定义的拦截里，我们获得用户调用的 Action 方法名，按美元符隔开获得后半部分的类名，指定的包名（这里是 com.dw.business）+ 类名就是业务模型类的全路径，使用 Java 反射机制动态生成一个空的业务模型对象（所以，业务模型类必须有一个无参的构造函数），设置到 Action 里，再交给装配器的时候，装配器会自动组装这个模型。该拦截器的核心代码如清单 4 所示。
public String intercept(ActionInvocation ai) throws Exception {
ai.addPreResultListener(this);
Main action = (Main)ai.getAction();
//业务方法名
String name = ai.getInvocationContext().getName();
int lastIndex = name.lastIndexOf("$");
if (lastIndex != -1)
{
try {
String head = "com.dw.business.";
String className = name.substring(lastIndex+1, name.length());
//关键：动态设置业务模型
action.setModel(Class.forName(head).newInstance());
} catch (Exception e) {}
}
return ai.invoke();
}
有了上面的配置，基本可以做到屏蔽大多数技术细节开发了，但是我们还有一个问题，当在业务方法中，意外抛出了异常，struts2 默认的是返回 INPUT，按照 清单 1 的配置，发生错误将跳转到 noDir/error.jsp 页面，显示错误信息，这适合在非 Ajax 的处理。但是有时候我们希望他返回错误是 JSON 类型，因为 Action 的一些方法是 Ajax 的调用方式，也就是 Action 方法的执行结果需要返回 errorJson。我的解决方法是利用 Java 注解技术，定义一个新的注解，名为 IfErrorReturnToJson，它的代码如清单 5 所示。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface IfErrorReturnToJson {
}
该注解作用在方法上，也就是 Action 的业务方法，如果我们希望某业务方法在发送错误时，就返回 JSON 类型，那么我们只需要在该方法上加上这个注解。现在，我们如何动态的修改返回值呢。清单 2 的第二行，为 ActionInvocation 添加了 PreResultListener，这个监听器是在返回结果前进行一些处理，正符合我们的需求。我们为自定义拦截器类实现了 PreResultListener 接口，实现了接口方法，如清单 6 所示。
public void beforeResult(ActionInvocation ai, String result) {
if (Main.INPUT.equals(result) || Main.ERROR.equals(result))
{
try {
String methodName = ai.getInvocationContext().getName();
Method method = Main.class.getMethod(methodName);
if (method != null && method.getAnnotation(
IfErrorReturnToJson.class) != null)
{
ai.setResultCode(Main.ERROR_JSON);
}
} catch (Exception e) {
}
}
}
可以看到，我们在返回结果前，如果当前的返回结果是 INPUT 或者 ERROR，我们会使用反射机制，检查该方法是否加了 IfErrorReturnToJson 的注解，如果加了注解，则调用 ai.setResultCode(Main.ERROR_JSON); 方法，修改返回值，使得结果为 JSON 数据类型。
在 SSH 开发中，需要重点考虑的是 Spring 的事务配置。根据不同的业务，定义的事务隔离级别就不同，比如对隔离级别要求高的，就要用到 Spring 的序列化读的隔离配置；有一些方法只是为了权限控制，用于页面跳转，则不需要用到事务控制；一些操作目的是搜索，那么该事务就是只读的。精细的事务配置，可以提高业务处理的代码效率。这时候，业务方法的命名规约就可以起到隔离级别的控制作用，比如方法名是 *begin*( 方法名中包含 begin)，则该方法没有事务控制；方法名是 *search* 的，则该方法拥有只读的事务；方法名是 *seri*，则用序列化读事务控制，提高并发安全级别。这个事务配置清单如所示。
在一些应用中，涉及到简单的权限管理。读者可能会想到一些开源的中间件，如 ralasafe 这样的开源权限组件，虽然很全面，但是学习起来需要一定的时间，熟练掌握，并配合 SSH 开发则更需要细致的学习。当我们只是简单的权限控制时，我们完全可以用到一些规约，来完成用户的权限控制。在我设计的规约中，需要在数据库中定义一张 Permission 表，代表权限 , 它与用户表是多对一的关系，它至少有两个字段，一个是 permissionName，一个是 permissionPrefix。permissionName 用于描述该权限，而 permissionPrefix 是我们所关心的。我们设计 Action 的方法，遵守 permissionPrefix_actionMethodName$BussinessBean 这样的原则，permissionPrefix 前缀代表数据库中权限表的 permissionPrefix 值 , 使用下划线隔开。当用户登录后，会将该用户所拥有的权限列表存放到 session 之中。当用户试图访问一个 Action Method 时，会使用 ModelDriven 的规约 里一样的方法，截取方法名获得该方法允许的访问权限，如果用户的权限列表中包含了该方法的权限，则允许调用，否则不允许调用。这样设计，虽然无法做到数据的访问权限，却可以满足一大部门的功能权限控制。这里需要记住，权限描述可以修改，但是权限的 permissionPrefix 不能修改，如果方法名中没有权限标识，则代表任何用户都可以访问。类似的，如果一个方法多个权限都可以访问，则可以这样设计方法 p1_p2_p3_methodName$BussinessBean，使用多个下划线分割。
基于 HTTP 协议的特殊性，上传到 Web 服务器的数值都是字符串，而我们的业务模型都是对象类型，有一些还是复杂的业务对象。Struts2 提供了 Conveter 的机制，允许程序员将 String 转换成复杂的业务对象。但是笔者刚用这个机制的时候，开始的确兴奋，但是随着业务的修改，业务模型的修改，这些 Conveter 的管理着实让人头疼。因此，本人认为 Conveter 技术应该尽量少用。我提出了一个新的方法，假设一个业务模型中，里面包含一个 List<People> pids 属性对象，People 里有一个 id 属性，我们需要客户端上传 People 的 id 列表，放入 List<People> pids 之中。如果使用 Conveter，我们在客户端需要定义规则，如客户端上传 pids=1,2,3,4,6,8。然后服务器端使用 Conveter 执行分割字符串、新建 People 对象、设置 ID、添加到列表等一系列操作。听着都头晕不是吗 ? 而且这相对并不安全，对程序员解析字符串的功底要求很高。我们感谢 Struts2 的传参机制，如果我们这样传参：<input name=”pids[0].id”/><input name=”pids[1].id”/>。这两个 input 的上传，Struts2 会根据上传数据的 name，自动组装成 List<People> 对象，并且赋值给 pids，pids[0] 代表列表的第 0 个元素，这用到了 OGNL 表达式的传参规则，它会自动识别 pids 是数组还是列表，如果 pids 默认是空，它还会自动新建一个空的数组或列表。笔者可以查看 OGNL 的相关教程。合理利用该技术，可以大大缩减传参的难度。
Struts2 提供了众多的标签，这些标签大致包括了 UI 标签、数据标签以及逻辑标签。这里，我们需要理解 UI 标签与服务器端的数据交互格式，比如 checkboxlist 标签，传到服务器端就是一个数组，该数组存放的是选定的 checkbox 列表的数值 , 这比使用 iterator 标签生成 checkbox 列表容易获得数据。Doubleselect 标签，用于生成 2 级的级联 select，经常使用的是部门 - 用户的级联。Optiontransferselect 标签，用于批量的迁移，比如用于批量的为部门分配用户。使用 struts2 的标签可以大大减少用户界面的开发，以及使得用户界面到服务器的数据传输方式变得非常简单。
Struts2 具有一套完善的验证机制，在 ActionSupport 类里，可以将模型验证方法写在 validate* 方法里。如果重写了 ActionSupport 的 validate 方法，这个 validate 会在执行所有 Action Method 前调用，执行验证。而自定义的 validate*（* 是方法名），比如方法名是 add，则这个方法名就是 validateAdd），它只会在执行 add 方法前执行验证。对于数据的验证，笔者建议使用 validater 文件验证，它更加容易配置和修改，利用现有的验证器，可以减少硬编码验证的痛苦。在上面提到的框架中，由于使用的是动态方法机制，我们需要在 Action 类所在的包里，新建 validator 的 XML 文件，名字是 { 类名 }-{ 方法名 }-validation.xml（如果不是动态的方法，则 { 类名 }-validation.xml 就足够了）。最后的结果如图 2 所示。
具体的配置内容，读者可以搜索 Struts2 的 validation 框架教程。
Struts2 提供的验证器，包括 date、required、requiredstring 等等，这些可以归于数据验证。而对于特定的业务模型验证，则比较复杂，因此，在该框架中，可以自定义一个业务验证器，这是 struts2 支持的，它负责对业务模型进行验证，比如可以验证用户上传的用户 ID 的用户是否存在，这可以在很大程度上保证系统的安全性。验证器的代码清单 7 如下面所示。
public class BusinessValidator extends FieldValidatorSupport {
private String property = null;
public String getProperty() {
return property;
}
public void setProperty(String property) {
this.property = property;
}
@Override
public void validate(Object exist) throws ValidationException {
String fieldName = getFieldName();
Object fieldValue = getFieldValue(fieldName, exist);
if (fieldValue != null && fieldValue instanceof Integer &&
((Integer)fieldValue) <= 0)
{
addFieldError("message", "上传的ID，该数据是不存在!");
} else if (fieldValue == null)
{
addFieldError("message", "上传的ID，该数据是不存在!");
} else {
if (exist != null && exist instanceof Main &&
((Main)exist).getModel() instanceof IChecker)
{
Main pa = (Main)exist;
IChecker e = (IChecker)pa.getModel();
boolean isRight = e.checkOk(property, pa);
if (!isRight)
{
addFieldError("message", "上传的ID，该数据是不存在!");
} else {
pa.getPubDao().getHibernateTemplate().clear();
}
}
}
}
}
清单 7 中，用到一个 IChecker 接口，需要验证的业务模型需要实现 IChecker 接口，在接口实现方法中实现业务验证过程，错误的话返回 false。
在 src 目录（或者 WEB-INF 下的 class 目录），添加 validater.xml 文件，在其他自带的验证器后，添加业务验证器配置，命名为 check。
<validators>
……
<validator name="check" class="com.attendance.action.BusinessValidator"/>
</validators>
接下来就可以使用这个验证器，在图 2 中的 validation 文件里，添加如清单 9 的配置。
<field-validator type="check" short-circuit="true"> <param name="property">department</param> <message> 该部门不存在 !</message> </field-validator>
利用 JEE Eclipse 生成 Hibernate 的 JPA 模型
IBM 提供了 JEE 版的 Eclipse，专门用于开发 Java EE 的应用，它提供了从数据库中生成符合 JPA 规范的数据模型的能力。Hibernate3 以后，支持了 JPA 规范（不是完全支持，但是已经较为全面），利用 JEE Eclipse 的生成能力，就可以避免繁琐的 hbm 文件的配置。同时，JPA 的规范里，还可以提供 NamedQuery、OrderBy 等注解，对于复杂的数据库，该规范可以减少开发时间。
Struts2 的 action 标签，用于调用某个 action。这个标签笔者认为非常有用，尤其体现在 UI 重用中，比如用户管理中，在很多个界面里，都允许用户信息修改和用户删除，那么我们就可以将用户信息修改和用户删除的页面代码以及 JavaScript 放在一个 JSP 里，同时定义一个 Action 方法 ( 名为 A)，为这个 JSP 执行初始化。接下来在允许进行用户修改和删除的界面，都用 s:action 标签调用这个 A 方法，设置 executeResult 为 true，将用户修改和删除的代码包含在页面里。这样就实现了 Action 的重用。如果重用的界面不需要服务器的初始化，这直接使用 jsp:include 或 s:include 引用重用的 JSP。
本文通过一系列的讲解，讲述了如何搭建一个通用的 SSH 开发框架，陈述了其中的设计思想，由于篇幅限制，文章只介绍了框架中的重要部分和重要思想，希望读者可以从中获益。由于笔者水平有限，如有错误，请联系我批评指正。
119
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
