Hibernate 能够满足我们的验证需求-UML软件工程组织-火龙果软件

本文内容

验证和应用程序层
对控制器添加验证
为视图添加验证
最后的考虑

尽管在 Web 应用程序中尽可能多的层次中构建数据验证非常重要，但是这样做却非常耗时，以至于很多开发人员都会干脆忽略这个步骤 —— 这可能会导致今后大量问题的产生。但是随着最新版本的 Java 平台中引入了注释，验证变得简单得多了。在本文中，Ted Bergeron 将向您介绍如何使用 Hibernate Annotations 的 Validator 组件在 Web 应用程序中轻松构建并维护验证逻辑。

　有时会有一种工具，它可以真正满足开发人员和架构师的需求。开发人员在第一次下载这种工具当天就可以在自己的应用程序中开始使用这种工具。理论上来说，这种工具在开发人员花费大量时间来掌握其用法之前就可以从中获益。架构师也很喜欢这种工具，因为它可以将开发人员导向更高理论层次的实现。Hibernate Annotations 的 Validator 组件就是一种这样的工具。

开始之前需要了解的内容

在阅读本文之前，应该对 Java 平台版本 5（尤其是注释）、JSP 2.0（因为本文中创建了一些标签文件，并在 TLD 中定义了一些函数，它们都是 JSP 2.0 的新特性）和 Hibernate 及 Spring 框架有一个基本的了解。请注意即使不使用 Hibernate 来实现持久性，也可以在自己的应用程序中使用 Hibernate Validator。

　Java SE 5 为 Java 语言提供了很多需要的增强功能，不过其他增强功能可能都不如注释这样潜力巨大。使用注释，我们就终于具有了一个标准、一级的元数据框架为 Java 类使用。Hibernate 用户手工编写 *.hbm.xml 文件已经很多年了（或者使用 XDoclet 来自动实现这个任务）。如果手工创建了 XML 文件，那就必须对每个所需要的持久属性都更新这两个文件（类定义和 XML 映射文档）。使用 HibernateDoclet 可以简化这个过程（请参看清单 1 给出的例子），但是这需要我们确认自己的 HibernateDoclet 版本支持要使用的 Hibernate 的版本。doclet 信息在运行时也是不可用的，因为它被编写到了 Javadoc 风格的注释中了。Hibernate Annotations，如图 2 所示，通过提供一个标准、简明的映射类的方法和所添加的运行时可用性来对这些方式进行改进。

清单 1. 使用 HibernateDoclet 的 Hibernate 映射代码

/**
* @hibernate.property column="NAME" length="60" not-null="true"
*/
public String getName() {
return this.name;
}

/**
* @hibernate.many-to-one column="AGENT_ID" not-null="true" cascade="none"
* outer-join="false" lazy="true"
*/
public Agent getAgent() {
return agent;
}
/**
* @hibernate.set lazy="true" inverse="true" cascade="all" table="DEPARTMENT"
* @hibernate.collection-one-to-many class="com.triview.model.Department"
* @hibernate.collection-key column="DEPARTMENT_ID" not-null="true"
*/
public List<Department> getDepartment() {
return department;
}

清单 2. 使用 Hibernate Annotations 的 Hibernate 映射代码

@NotNull
@Column(name = "name")
@Length(min = 1, max = NAME_LENGTH) // NAME_LENGTH is a constant declared elsewhere
public String getName() {
return name;
}

@NotNull
@ManyToOne(cascade = {CascadeType.MERGE }, fetch = FetchType.LAZY)
@JoinColumn(name = "agent_id")
public Agent getAgent() {
return agent;
}

@OneToMany(mappedBy = "customer", fetch = FetchType.LAZY)
public List<Department> getDepartment() {
return department;
}

如果使用 HibernateDoclet，那么直到生成 XML 文件或运行时才能捕获错误。使用注释，在编译时就可以检测出很多错误；或者如果在编辑时使用了很好的 IDE，那么在编辑时就可以检测出部分错误。在从头创建应用程序时，可以利用 hbm2ddl 工具为自己的数据库从 hbm.xml 文件中生成 DDL。一些重要的信息 —— 比如name 属性的最大长度必须是 60 个字符，或者 DDL 应该添加非空约束 —— 都被从 HibernateDoclet 项添加到 DDL 中。当使用注释时，我们可以以类似的方式自动生成 DDL。

尽管这两种代码映射方式都可以使用，不过注释的优势更为明显。使用注释，可以用一些常量来指定长度或其他值。编译循环的速度更快，并且不需要生成 XML 文件。其中最大的优势是可以访问一些有用信息，例如运行时的非空注释或长度。除了清单 2 给出的注释之外，还可以指定一些验证的约束。所包含的部分约束如下：

@Max(value = 100)
@Min(value = 0)
@Past
@Future
@Email

在适当条件下，这些注释会引起由 DDL 生成检查约束。（显然，@Future 并不是一个适当的条件。）还可以根据需要创建定制约束注释。

验证和应用程序层

编写验证代码是一个烦人且耗时的过程。通常，很多开发人员都会放弃在特定的层进行有效性验证，从而可以节省一些时间；但是所节省的时间是否能够弥补在这个地方因忽略部分功能所引起的缺陷却非常值得探讨。如果在所有应用程序层中创建并维护验证所需要的时间可以极大地减少，那么争论的焦点就会转向是否要在多个层次中进行有效性验证。假设有一个应用程序，它让用户使用一个用户名、密码和信用卡号来创建一个帐号。在这个应用程序中所希望进行验证的组件如下：

视图： 通过 JavaScript 进行验证可以避免与服务器反复进行交互，这样可以提供更好的用户体验。用户可以禁用 JavaScript，因此这个层次的验证最好要有，但是却并不可靠。对所需要的域进行简单的验证是必须的。
控制器： 验证必须在服务器端的逻辑中进行处理。这个层次中的代码可以以适合某个特定用途的方式处理验证。例如，在添加新用户时，控制器可以在进行处理之前检查指定的用户名是否已经存在。
服务： 相对复杂的业务逻辑验证通常都最适合放到服务层中。例如，一旦有一个信用卡对象看起来有效，就应该使用信用卡处理服务对这个信用卡的信息进行确认。
DAO： 在数据到达这个层次时，应该已经是有效的了。尽管如此，执行一次快速检查从而确保所需要的域都非空并且值也都在特定的范围或遵循特定的格式（例如 e-mail 地址域就应该包含一个有效的 e-mail 地址）也是非常有益的。在此处捕获错误总比产生可以避免的 SQLException 错误要好。
DBMS： 这是通常可以忽略验证的地方。即使当前正在构建的应用程序是数据库的惟一客户机，将来还可能会添加其他客户机。如果应用程序有一些 bug（大部分应用程序都可能会有 bug），那么无效的数据也可能会被发送给数据库。在这种情况中，如果走运，就可以找到无效的数据，并且需要分析这些数据是否可以清除，以及如何清除。
模型： 这是进行验证的一个理想地方，它不需要访问外部服务，也不需要了解持久性数据。例如，某业务逻辑可能会要求用户至少提供一个联系信息，这可以是一个电话号码也可以是一个 e-mail 地址；可以使用模型层的验证来确保用户的确提供了这种信息。

　进行验证的一种典型方法是对简单的验证使用 Commons Validator，并在控制器中编写其他一些验证逻辑。Commons Validator 可以生成 JavaScript 来对视图中的验证进行处理。但是 Commons Validator 也有自己的缺陷：它只能处理简单的验证问题，并且将验证的信息都保存到了 XML 文件中。Commons Validator 被设计用来与 Struts 一起使用，而且没有提供一种简单的方法在应用程序层间重用验证的声明。

在规划有效性验证策略时，选择在错误发生时简单地处理这些错误是远远不够的。一种良好的设计同时还要通过生成一个友好的用户界面来防止出现错误。采用预先进行的方法进行验证可以极大地增强用户对于应用程序的理解。不幸的是，Commons Validator 并没有对此提供支持。假设希望 HTML 文件设置文本域的 maxlength 属性来与验证匹配，或者在文本域之后放上一个百分号（%）来表示要输入百分比的值。通常，这些信息都被硬编写到 HTML 文档中了。如果决定修改 name 属性来支持 75 个字符，而不是 60 个字符，那么需要改动多少地方呢？在很多应用程序中，通常都需要：

更新 DDL 来增大数据库列的长度（通过 HibernateDoclet、 hbm.xml 或 Hibernate Annotations）。
更新 Commons Validator XML 文件将最大值增加到 75。
更新所有与这个域有关的 HTML 表单，以修改 maxlength 属性。

更好的方法是使用 Hibernate Validator。验证的定义都被通过注释添加到了模型层中，同时还有对所包含的验证处理的支持。如果选择充分利用所有的 Hibernate，这个 Validator 就可以在 DAO 和 DBMS 层也提供验证。在下面给出的样例代码中，将使用 reflection 和 JSP 2.0 标签文件多执行一个步骤，从而充分利用注释为视图层动态生成代码。这可以清除在视图中使用的硬编写的业务逻辑。

在清单 3 中，dateOfBirth 被注释为 NotNull 和过去的日期。 Hibernate 的 DDL 生成代码对这个列添加了一个非空约束，以及一个要求日期必须是之前日期的检查约束。e-mail 地址也是非空的，必须匹配 e-mail 地址的格式。这会生成一个非空约束，但是不会生成匹配这种格式的检查约束。

　清单 3. 通过 Hibernate Annotations 进行映射的简单联系方式

/**
* A Simplified object that stores contact information.
*
* @author Ted Bergeron
* @version $Id: Contact.java,v 1.1 2006/04/24 03:39:34 ted Exp $
*/
@MappedSuperclass
@Embeddable
public class Contact implements Serializable {
public static final int MAX_FIRST_NAME = 30;
public static final int MAX_MIDDLE_NAME = 1;
public static final int MAX_LAST_NAME = 30;

private String fname;
private String mi;
private String lname;
private Date dateOfBirth;
private String emailAddress;

private Address address;

public Contact() {
this.address = new Address();
}

@Valid
@Embedded
public Address getAddress() {
return address;
}

public void setAddress(Address a) {
if (a == null) {
address = new Address();
} else {
address = a;
}
}

@NotNull
@Length(min = 1, max = MAX_FIRST_NAME)
@Column(name = "fname")
public String getFirstname() {
return fname;
}

public void setFirstname(String fname) {
this.fname = fname;
}

@Length(min = 1, max = MAX_MIDDLE_NAME)
@Column(name = "mi")
public String getMi() {
return mi;
}

public void setMi(String mi) {
this.mi = mi;
}

@NotNull
@Length(min = 1, max = MAX_LAST_NAME)
@Column(name = "lname")
public String getLastname() {
return lname;
}

public void setLastname(String lname) {
this.lname = lname;
}

@NotNull
@Past
@Column(name = "dob")
public Date getDateOfBirth() {
return dateOfBirth;
}

public void setDateOfBirth(Date dateOfBirth) {
this.dateOfBirth = dateOfBirth;
}

@NotNull
@Email
@Column(name = "email")
public String getEmailAddress() {
return emailAddress;
}

public void setEmailAddress(String emailAddress) {
this.emailAddress = emailAddress;
}

样例应用程序

　在下载一节，您可以下载一个样例应用程序，它展示了本文中采用的设计思想和代码。由于这是一个可以工作的应用程序，因此代码比本文中讨论的的内容更为复杂。例如，清单 9 就节选于标签文件 text.tag；这个样例应用程序具有标签文件使用的所有代码，以及其他三个类似的标签文件使用的代码（用于选择、隐藏和检查框的 HTML 元素）。由于这是一个可以工作的应用程序，它包含了一个在这种类型的应用程序中都可以找到的架构。还有一个 Ant 构建文件、Spring 和 Hibernate XML 封装代码，以及 log4j 配置。虽然这些都不是本文介绍的重点，但是您会发现仔细研究一下这个样例应用程序的源代码是非常有用的。

　如果需要，Hibernate DAO 实现也可以使用 Validation Annotations。所需做的是在 hibernate.cfg.xml 文件中指定基于 Hibernate 事件的验证规则。（更多信息请参考 Hibernate Validator 的文档；可以在参考资料一节中找到相关的链接）。如果真地希望抄近路，您可以只捕获服务或控制器中的 InvalidStateException 异常，并循环遍历 InvalidValue 数组。

对控制器添加验证

要执行验证，需要创建一个 Hibernate 的 ClassValidator 实例。这个类进行实例化的代价可能会很高，因此最好只对希望进行验证的每个类来进行实例化。一种方法是创建一个实用工具类，对每个模型对象存储一个 ClassValidator 实例，如清单 4 所示：

清单 4. 处理验证的实用工具类

/**
* Handles validations based on the Hibernate Annotations Validator framework.
* @author Ted Bergeron
* @version $Id: AnnotationValidator.java,v 1.5 2006/01/20 17:34:09 ted Exp $
*/
public class AnnotationValidator {
private static Log log = LogFactory.getLog(AnnotationValidator.class);

// It is considered a good practice to execute these lines once and
// cache the validator instances.
public static final ClassValidator<Customer> CUSTOMER_VALIDATOR =
new ClassValidator<Customer>(Customer.class);
public static final ClassValidator<CreditCard> CREDIT_CARD_VALIDATOR =
new ClassValidator<CreditCard>(CreditCard.class);

private static ClassValidator<? extends BaseObject> getValidator(Class<?
extends BaseObject> clazz) {
if (Customer.class.equals(clazz)) {
return CUSTOMER_VALIDATOR;
} else if (CreditCard.class.equals(clazz)) {
return CREDIT_CARD_VALIDATOR;
} else {
throw new IllegalArgumentException("Unsupported class was passed.");
}
}

public static InvalidValue[] getInvalidValues(BaseObject modelObject) {
String nullProperty = null;
return getInvalidValues(modelObject, nullProperty);
}

public static InvalidValue[] getInvalidValues(BaseObject modelObject,
String property) {
Class<? extends BaseObject>clazz = modelObject.getClass();
ClassValidator validator = getValidator(clazz);

InvalidValue[] validationMessages;

if (property == null) {
validationMessages = validator.getInvalidValues(modelObject);
} else {
// only get invalid values for specified property.
// For example, "city" applies to getCity() method.
validationMessages = validator.getInvalidValues(modelObject, property);
}
return validationMessages;
}
}

在清单 4 中，创建了两个 ClassValidator，一个用于 Customer，另外一个用于 CreditCard。这两个希望进行验证的类可以调用 getInvalidValues(BaseObject modelObject)，会返回 InvalidValue[]。这则会返回一个包含模型对象实例错误的数组。另外，这个方法也可以通过提供一个特定的属性名来调用，这样做会只返回与该域有关的错误。

在使用 Spring MVC 和 Hibernate Validator 时，为信用卡创建一个验证过程变得非常简单，如清单 5 所示：

清单 5. Spring MVC 控制器使用的 CreditCardValidator

/**
* Performs validation of a CreditCard in Spring MVC.
*
* @author Ted Bergeron
* @version $Id: CreditCardValidator.java,v 1.2 2006/02/10 21:53:50 ted Exp $
*/
public class CreditCardValidator implements Validator {

private CreditCardService creditCardService;

public void setCreditCardService(CreditCardService service) {
this.creditCardService = service;
}

public boolean supports(Class clazz) {
return CreditCard.class.isAssignableFrom(clazz);
}

public void validate(Object object, Errors errors) {
CreditCard creditCard = (CreditCard) object;

InvalidValue[] invalids = AnnotationValidator.getInvalidValues(creditCard);

// Perform "expensive" validation only if no simple errors found above.
if (invalids == null || invalids.length == 0) {
boolean validCard = creditCardService.validateCreditCard(creditCard);
if (!validCard) {
errors.reject("error.creditcard.invalid");
}
} else {
for (InvalidValue invalidValue : invalids) {
errors.rejectValue(invalidValue.getPropertyPath(),
null, invalidValue.getMessage());
}
}
}
}

validate() 方法只需要将 creditCard 实例传递给这个验证过程，从而返回 InvalidValue 数组。如果发现了一个或多个这种简单错误，那么就可以将 Hibernate 的 InvalidValue 数组转换成 Spring 的 Errors 对象。如果用户已经创建了这个信用卡并且没有出现任何简单错误，就可以将更加彻底的验证委托给服务层进行。这一层可以与商业服务提供者一起对信用卡进行验证。

现在我们已经看到这个简单的模型层注释是如何平衡到控制器、DAO 和 DBMS 层的验证的。在 HibernateDoclet 和 Commons Validator 中发现的验证逻辑的重合现在都已经统一到模型中了。尽管这是一个非常受欢迎的改进，但是视图层传统上来说一直是最需要进行详细验证的地方。

回页首

为视图添加验证

在下面的例子中，使用了 Spring MVC 和 JSP 2.0 标签文件。JSP 2.0 允许在 TLD 文件中对定制函数进行注册，并在一个标签文件中进行调用。标签文件类似于 taglibs，但是它们是使用 JSP 代码编写的，而不是使用 Java 代码编写的。采用这种方法，使用 Java 语言写好的代码就可以封装成函数，而使用 JSP 写好的代码则可以放入标签文件中。在这种情况中，对注释的处理需要使用映像，这会由几个函数来执行。绑定 Spring 或呈现 XHTML 的代码也是标签文件的一部分。

清单 6 中节选的 TLD 代码定义 text.tag 文件可以使用，并定义了一个名为 required 的函数。

清单 6. 创建表单 TLD

<?xml version="1.0" encoding="ISO-8859-1" ?>
<taglib xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsd"
version="2.0">

<tlib-version>1.0</tlib-version>
<short-name>form</short-name>
<uri>formtags</uri>

<tag-file>
<name>text</name>
<path>/WEB-INF/tags/form/text.tag</path>
</tag-file>

<function>
<description>determine if field is required from Annotations</description>
<name>required</name>
<function-class>com.triview.web.Utilities</function-class>
<function-signature>Boolean required(java.lang.Object,java.lang.String)
</function-signature>
</function>

</taglib>

清单 7 节选自 Utilities 类，其中包含了标签文件使用的所有函数。在前文中我们曾经说过，最适合使用 Java 代码编写的代码都被放到了几个 TLD 可以映射的函数中，这样标签文件就可以使用它们了；这些函数都是在 Utilities 类中进行编码的。因此，我们需要三样东西：定义这些类的 TLD 文件、Utilities 中的函数，以及标签文件本身，后者要使用这些函数。（第四样应该是使用这个标签文件的 JSP 页面。）

在清单 7 中，给出了在 TLD 中引用的函数和另外一个表示给定属性是否是 Date 的方法。在这个类中要涉及到比较多的代码，但是本文限于篇幅，不会给出所有的代码；不过需要注意 findGetterMethod() 除了将表达式语言（Expression Language，EL）方法表示（customer.contact）转换成 Java 表示（customer.getContact()）之外，还执行了基本的映像操作。

清单 7. Utilities 节选

public static Boolean required(Object object, String propertyPath) {
Method getMethod = findGetterMethod(object, propertyPath);
if (getMethod == null) {
return null;
} else {
return getMethod.isAnnotationPresent(NotNull.class);
}
}

public static Boolean isDate(Object object, String propertyPath) {
return java.util.Date.class.equals(getReturnType(object, propertyPath));
}

public static Class getReturnType(Object object, String propertyPath) {
Method getMethod = findGetterMethod(object, propertyPath);
if (getMethod == null) {
return null;
} else {
return getMethod.getReturnType();
}
}

此处可以清楚地看到在运行时使用 Validation annotations 是多么容易。可以简单地引用对象的 getter 方法，并检查这个方法是否有相关的给定的注释。

清单 8 中给出的 JSP 例子进行了简化，这样就可以着重查看相关的部分了。此处，这里有一个表单，它有一个选择框和两个输入域。所有这些域都是通过在 form.tld 文件中声明的标签文件进行呈现的。标签文件被设计成使用智能缺省值，这样就可以根据需要允许简单编码的 JSP 可以有定义更多信息的选项。关键的属性是 propertyPath，它使用 EL 符号将这个域映射为模型层属性，就像是使用 Spring MVC 的 bind 标签一样。

　清单 8. 一个包含表单的简单 JSP 页面

<%@ taglib tagdir="/WEB-INF/tags/form" prefix="form" %>

<form:select propertyPath="creditCard.type" collection="${creditCardTypeCollection}"
required="true" labelKey="prompt.creditcard.type"/>

<form:text propertyPath="creditCard.number" labelKey="prompt.creditcard.number">
<img src="<c:url value="/images/icons/help.png"/>" alt="Help"
onclick="new Effect.SlideDown('creditCardHelp')"/>
</form:text>

<form:text propertyPath="creditCard.expirationDate"/>
</form>

text.tag 文件的完整源代码太大了，不好放在这儿，因此清单 9 给出了其中关键的部分：

清单 9. 标签文件 text.tag 节选

<%@ attribute name="propertyPath" required="true" %>

<%@ attribute name="size" required="false" type="java.lang.Integer" %>

<%@ attribute name="maxlength" required="false" type="java.lang.Integer" %>

<%@ attribute name="required" required="false" type="java.lang.Boolean" %>

<%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %>

<%@ taglib uri="formtags" prefix="form" %>

<c:set var="objectPath" value="${form:getObjectPath(propertyPath)}"/>

<spring:bind path="${objectPath}">

<c:set var="object" value="${status.value}"/>

<c:if test="${object == null}">

<%-- Bind ignores the command object prefix, so simple properties of the command object

return null above. --%>

<c:set var="object" value="${commandObject}"/>

<%-- We depend on the controller adding this to request. --%>

</c:if>

</spring:bind>

<%-- If user did not specify whether this field is required,
query the object for this info. --%>

<c:if test="${required == null}">

<c:set var="required" value="${form:required(object,propertyPath)}"/>

</c:if>

<c:choose>

<c:when test="${required == null || required == false}">

<c:set var="labelClass" value="optional"/>

</c:when>

<c:otherwise>

<c:set var="labelClass" value="required"/>

</c:otherwise>

</c:choose>

<c:if test="${maxlength == null}">

<c:set var="maxlength" value="${form:maxLength(object,propertyPath)}"/>

</c:if>

<c:set var="isDate" value="${form:isDate(object,propertyPath)}"/>

<c:set var="cssClass" value="input_text"/>

<c:if test="${isDate}">

<c:set var="cssClass" value="input_date"/>

</c:if>

<spring:bind path="${propertyPath}">

<label for="${status.expression}" class="${labelClass}"><fmt:message

key="prompt.${propertyPath}"/></label>

<input type="text" name="${status.expression}" value="${status.value}"

id="${status.expression}"<c:if test="${size != null}"> size="${size}"</c:if>

<c:if test="${maxlength != null}"> maxlength="${maxlength}"</c:if>

class="${cssClass}"/>

<c:if test="${isDate}">

<img id="${status.expression}_button"

src="<c:url value="/images/icons/calendar.png"/>" alt="calendar"

style="cursor: pointer;"/>

Calendar.setup(

{

inputField : "${status.expression}", // ID of the input field

ifFormat : "%m/%d/%Y", // the date format

button : "${status.expression}_button" // ID of the button

}

);

</script>

</c:if>

<c:if test="${status.errorMessage != null && status.errorMessage != ''}">

<p class="fieldError"><img id="${status.expression}_error"

src="<c:url value="/images/icons/error.png"/>"

alt="error"/>${status.errorMessage}</p>

</c:if>

</spring:bind>

</div>

我们马上就可以看出 propertyPath 是惟一需要的属性。size、 maxlength 和 required 都可以忽略。objectPath var 被设置为在 propertyPath 中引用的属性的父对象。因此，如果 propertyPath 是 customer.contact.fax.number，那么 objectPath 就应该被设置为 customer.contact.fax。我们现在就使用 Spring 的 bind 标签绑定到了包含属性的对象上。这会将对象变量设置成对包含属性的实例的引用。接下来，检查这个标签的用户是否已经指定他/她们是否希望属性是必须的。允许表单开发人员覆盖从注释中返回的值是非常重要的，因为有时他/她们希望让控制器为所需要的域设置缺省值，而用户可能并不希望为这个域提供值。如果表单开发人员没有为 required 指定值，那么就可以调用这个表单 TLD 的 required 函数。这个函数调用了在 TLD 文件中映射的方法。这个方法简单地检查 @NotNull 注释；如果它发现某个属性具有这个注释，就将 labelClass 变量设置为必须的。可以类似地确定正确的 maxlength 以及这个域是否是一个 Date。

接下来使用 Spring 来绑定到 propertyPath 上，而不是像前面一样只绑定到包含这个属性的对象上。这允许在生成 label 和 input HTML 标签时使用 status.expression 和 status.value。 input 标签也可以使用一个大小 maxlength 以及适当的类来生成。如果前面已经确定属性是一个 Date，现在就可以添加 JavaScript 日历了。（可以在参考资料一节找到一个很好的日历组件的链接）。注意根据需要链接属性、输入 ID 和图像 ID 的标签是多么简单。）这个 JavaScript 日历需要一个图像 ID 来匹配输入域，其后缀是 _button。

最后，可以将 <jsp:doBody/> 封装到一个 span 标签中，这样允许表单开发人员在页面中添加其他图标，例如用来寻求帮助的图标。（清单 8 给出了一个为信用卡号域添加的帮助图标。）最后的部分是检查 Spring 是否为这个属性报告和显示了一个错误，并和一个错误图标一起显示。

使用 CSS，就可以对必须的域进行一下装饰 —— 例如，让它们以红色显示、在文本边上显示一个星号，或者使用一个背景图像来装饰它。在清单 10 中，将必须的域的标签设置成黑色，而且后面显示一个红色的星号（在 Firefox 以及其他标准兼容的浏览器中），如果是在 IE 中则还会在左边加上一个小旗子的背景图像：

　清单 10. 对必须域进行装饰的 CSS 代码

label.required {
color: black;
background-image: url( /images/icons/flag_red.png );
background-position: left;
background-repeat: no-repeat;
}
label.required:after {
content: '*';
}
label.optional {
color: black;
}

日期输入域自动会在右边放上一个 JavaScript 日历图标。对所有的文本域设置正确的 maxlength 属性可以防止用户输入太多文本所引起的错误。可以扩展 text 标签来为输入域类设置其他的数据类型。可以修改 text 标签使用 HTML，而不是 XHTML（如果希望这样）。可以不太费力地获得具有正确语义的 HTML 表单，而且不需学习基于组件的框架知识，就可以利用基于组件的 Web 框架的优点。

尽管标签文件生成的 HTML 文件可以帮助防止一些错误的产生，但是在视图层并没有任何代码来真正进行错误检查。由于可以使用类属性，现在就可以添加一些简单的 JavaScript 来实现这种功能了，如清单 11 所示。这里的 JavaScript 也可以是通用的，在任一表单中都可以重用。

　清单 11. 简单的 JavaScript 验证程序

var labelText = requiredLabels[i].firstChild.nodeValue; // Get the label's text
var labelFor = requiredLabels[i].getAttribute("for"); // Grab the for attribute
var inputTag = document.getElementById(labelFor); // Get the input tag

if (inputTag.value == null || inputTag.value == "") {
alert("Please make sure all required fields have been entered.");
return false; // Abort Submit
}
}
return true;
}
</script>

这个 JavaScript 是通过为表单声明添加 onsubmit="return checkRequired(this);" 被调用的。这个脚本简单地获取具有所需要的类的表单中的所有元素。由于我们的习惯是在标签标记中使用这个类，因此代码会通过 for 属性来查找与这个标签连接在一起的输入域。如果任何输入域为空，就会生成一条简单的警告消息，表单提交就会取消。可以简单地对这个脚本进行扩充，使其扫描多个类，并相应地进行验证。

对于基于 JavaScript 的综合的验证集合来说，最好是使用开源实现，而不是自行开发。在清单 8 中您可能已经注意到下面的代码：

onclick="new Effect.SlideDown('creditCardHelp')"

这个函数是 Script.aculo.us 库的一部分，这个库提供了很多高级的效果。如果正在使用 Script.aculo.us，就需要对所构建的内容使用 Prototype 库。 JavaScript 验证库的一个例子是由 Andrew Tetlaw 在 Prototype 基础上构建的。（请参看参考资料一节中的链接。）他的框架依赖于被添加到输入域的类：

可以简单地修改 text.tag 的逻辑在 input 标签中插入几个类。将 class="required" 添加到输入标签和 label 标签中不会影响 CSS 规则，但会破坏清单 10 中给出的简单 JavaScript 验证程序。如果要混合使用框架中的代码和简单的 JavaScript 代码，最好使用不同的类名，或在使用类名搜索元素时确保类名有效并检查标签类型。

回页首

最后的考虑

本文已经介绍了模型层的注释如何充分用来在视图、控制器、DAO 和 DBMS 层中创建验证。必须手工创建服务层的验证，例如信用卡验证。其他模型层的验证，例如强制属性 C 是必须的，而属性 A 和 B 都处于指定的状态，这也是一个手工任务。然而，使用 Hibernate Annotations 的 Validator 组件，就可以轻松地声明并应用大多数验证。

展望

不论是简单例子还是所引用框架的 JavaScript 验证都可以对简单的条件进行检查，例如域必须要填写，或者客户机端代码中的数据类型必须要匹配预期的类型。需要用到服务器端逻辑的验证可以使用 Ajax 添加到 JavaScript 验证程序中。您可以使用一个用户注册界面来让用户可以选择用户名。文本标签可以进行增强来检查 @Column(unique = true) 注释。在找到这个注释时，标签可以添加一个用来触发 Ajax 调用的类。

现在您不需要在应用程序层间维护重复的验证逻辑了，这样就可以节省出大量的开发时间。想像一下您最终可以为应用程序所能添加的增强功能！