Bean 验证规范初稿发布

在大多数企业级应用中，数据约束会存在于下面两个地方：
1. 模型中（比较典型的就是数据库架构约束）。
2. 应用程序代码中。
这两处都非常重要。在需要迁移应用程序代码的情况下，数据库约束允许重用底层数据模型。与用模型级约束轻松实现的粒度控制比起来，应用级验证能提供更好的粒度控制（这是不是一个有效的 E-mail 地址？客户的生日是否尚未到来？），也能更容易地为应用用户提供有意义的错误信息。应用级验证可以完全存在于多个地方，从而造成应用不同层之间大量的重复工作。举例来说，在一个典型的 Web 应用中，浏览器会执行 JavaScript 进行简单的域级验证，服务器层则验证更为复杂的业务规则。能在一个地方集中定义验证、在应用的不同层之间共享这些定义，该是非常可取的。

在 Hibernate Validator 高级开发人员 Emmanuel Bernard 的带领下，JSR-303 旨在标准化 Java EE 6 的约束元数据模型。规范的初稿已经发布，专家组也在积极征求反馈。做为这项工作的一部分，已经创建了一个论坛，Bernard 也开始在Hibernate 的博客中发表一系列描述API 工作原理的文章（第一部分，第二部分）。

知道了JSR-303 规范的起源，JSR-303 很大程度上受JBoss Hibernate Validations 的影响也就不足为怪了，尽管很多其它验证框架（比如Xwork 和Apache Commons Validator）也影响了该规范。JSR-303 在大多数情况下使用Annotation，并为运行时验证提供标准的APIs 来查询元数据。每个约束Annotation 都必须定义一个String 类型的信息来创建错误信息。错误信息支持国际化。可以对对象的属性、Get 方法、类、父类、接口声明约束，验证对象会验证该对象所有的约束。比如说，下面的代码创建了一个叫street1 的字符串，它的最大长度是50 个字符，而且不允许为空：

@NotEmpty @Max(50)<br id="hzqs"></br>private String street1;

该框架设计为可扩展的，所以应用能很容易地定义自己特有的补充约束。第一篇博客文章中写道：

“约束由下面部分构成：
• Annotation
• 约束验证实现
Annotation 表示对域模型的约束，而验证实现则判断给定的值能否通过约束。”

规范不仅支持实例验证，也支持对象图的验证，那么举例来说，如果 ClientDetails Bean 包含一个带有一或多个 @Valid Annotation 的 Address Bean，验证器在验证 ClientDetails Bean 的时候也会验证 Address Bean 的内容。

规范和 Hibernate Validator 之间的一个重要不同是组的概念，组提供了创建验证子集的方法。组有一个关联序列（通过 @GroupSequence Annotation 设置），所以开发人员可以在下一组约束执行之前强制通过一组约束而不产生错误。组也允许 JavaBean 的部分验证。规范初稿提出了可能有用的两种场景：

“• 第二种组完全运行需要依赖于稳定状态
• 第二种组会严重消耗时间、CPU 或内存，应该尽可能避免使用”

Java EE 6 平台中多种技术都应该能利用 JSR-303。比如说，用 ORM 工具生成（DDL）时的 DLL 更新、由 Java 持久化 API 进行的插入 / 更新的实体验证、新的 WebBeans API、JavaServerFaces 组件，看似都很有希望。查看英文原文： Initial Draft of the Bean Validation Specification Released