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)
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