在使用jpa时，比如我使用hibernate作为实现，默认情况下如果classpath下有bean validation实现会自动开启JSR-303验证。其通过Listener实现，即可以在如insert、update之前执行验证，如果验证失败会直接抛出验证失败异常。接下来可进行异常处理。
现在的问题是：
1、比如我们在Web层进行验证，如使用SpringMVC，此时我们可以直接在web层使用JSR-303验证，而且可以控制 什么时候需要验证；
2、当然也可以在业务逻辑层进行，这个可以参考Spring3.1 对Bean Validation规范的新支持(方法级别验证)；
3、现在jpa也支持验证实体。
所以此时如果不希望jpa进行验证，可以考虑使用如下代码进行关闭：
<!-- 使用自定义的validator进行jsr303验证 -->
<entry key="javax.persistence.validation.factory" value-ref="validator"/>
<!-- jsr303验证模式 因为其要么验证 要么不验证 不能按照规则走 所以此处禁用 -->
<entry key="javax.persistence.validation.mode" value="${javax.persistence.validation.mode}"/>
为什么jpa默认的实现不好呢？这里给大家举个例子：
发送消息：
标题：5-200个字符
内容：5-50000个字符
假设用户编辑了一个消息，此时用户在发送时突然有事要离开，这个时候发现内容还没写，要保存草稿，如果此时保存，会进行jpa的bean validation，此时肯定不通过，但是对于这种情景我们是不需要的。
因此这种注解的验证，只能满足大部分需求，如果一旦满足不了，连不想用都不行。即要么全用，要么全不用。即使用XML方式也会有这个问题。
解决方案：
应该提供一些开关数据来控制，改变那种要么全 要么无的方案。
但是bean validation也提供了分组的概念，即按组验证，但是这个对我们来说没有什么用处。
<property name="javax.persistence.validation.group.pre-update"
value="javax.validation.group.Default, com.acme.group.Strict"/>
具体可参考其官方文档：
http://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#d5e9828
而且现在注解使用的越来越广泛；它的主要好处是写起来比xml要方便的多，但是它们的目的都是一样的，元数据。
我的理解：
注解：是一种分散式的元数据，与源代码紧绑定。
xml：是一种集中式的元数据，与源代码无绑定。
因此注解和XML的选择上可以从两个角度来看：分散还是集中，源代码绑定/无绑定。
注解的缺点：
1、很多朋友比如在使用spring注解时，会发现注解分散到很多类中，不好管理和维护；这个其实要借助工具，我目前使用的是IDEA，它在这方面表现的非常好；当然现在还有Spring的STS，也是不错的； 所以借助工具，能解决这个问题；
2、注解的开启/关闭必须修改源代码，因为注解是源代码绑定的，如果要修改，需要改源码，这个有这个问题，所以如果是这种情况，还是使用XML配置方式；比如数据源；
3、注解还一个缺点就是灵活性，比如在之前翻译的Spring Framework 4.0 M1: WebSocket 支持；在实现复杂的逻辑上，没有XML来的更加强大；注解就是要么用，要么不用，比如之前的jpa bean validation，要么全，要么没；遇到这种情况很痛苦；
4、还一种就是约定大于配置，但是在处理一些复杂的情况下，注解还是需要的（如Spring的数据验证/数据绑定注解很强大）；
5、通用配置还是走XML吧，比如事务配置，比如数据库连接池等等，即通用的配置集中化，而不是分散化，如很多人使用@Transactional来配置事务，在很多情况下这是一种太分散化的配置；
6、XML方式比注解的可扩展性和复杂性维护上好的多，比如需要哪些组件，不需要哪些；在面对这种情况，注解扫描机制比较逊色，因为规则很难去写或根本不可能写出来；
注解的好处：
1、XML配置起来有时候冗长，此时注解可能是更好的选择，如jpa的实体映射；注解在处理一些不变的元数据时有时候比XML方便的多，比如springmvc的数据绑定，如果用xml写的代码会多的多；
2、注解最大的好处就是简化了XML配置；其实大部分注解一定确定后很少会改变，所以在一些中小项目中使用注解反而提供了开发效率，所以没必要一头走到黑；
3、注解相对于XML的另一个好处是类型安全的，XML只能在运行期才能发现问题。
注解也好，XML也好，我们还是需要一些开关/替换机制来控制特殊需求，以改变那种要么全部 要么没有的方案。。
还一种呼声就是约定大于配置，这种方案可能在某些场景下是最优的，但是遇到一些复杂的情况可能并不能解决问题，所以此时注解也是一个不错的方案。尤其在使用springmvc时，好处是能体会的出的。
不管使用注解还是XML，做的事情还是那些事情，但注解和XML都不是万能的，满足自己的需求且已一种更简单的方式解决掉问题即可。
就像探讨一下技术问题，很多人都带有很强的个人喜好来评判一个东西的好坏，这种探讨没有任何意义，我们最终的目的是解决方案，所以我们应该探讨的是能不能解决问题，能不能以更容易理解的方式解决问题，能不能更简单的解决问题。
不管是约定大于配置、注解还是XML配置也好，没有哪个是最优的，在合适的场景选择合适的解决方案这才是重要的。就像设计模式一样：是对特定环境中重复出现的特定问题的一个经过前人验证了的解决方案。
欢迎拍砖，探讨。