JPA 2.0动态查询Criteria.doc

详解JPA 2.0动态查询机制:Criteria API 自从 JPA 于 2006 年首次被引入之后，它就得到了 Java 开发社区的广泛支持。该规范的下一个主要更新 —— 2.0 版本 (JSR 317) —— 将在 2009 年年底完成。JPA 2.0 引入的关键特性之一就是 Criteria API，它为 Java 语言带来了一种独特的能力：开发一种 Java 编译器可以在运行时验证其正确性的查询。Criteria API 还提供一个能够在运行时动态地构建查询的机制。 本文将介绍 Criteria API 和与之密切相关的 元模型（metamodel）概念。您将学习如何使用 Criteria API 开发 Java 编译器能够检查其正确性的查询，从而减少运行时错误，这种查询优于传统的基于字符串的 Java Persistence Query Language (JPQL) 查询。借助使用数据库函数或匹配模板实例的样例查询，我将演示编程式查询构造机制的强大威力，并将其与使用预定义语法的 JPQL 查询进行对比。本文假设您具备基础的 Java 语言编程知识，并了解常见的 JPA 使用，比如 EntityManagerFactory 或 EntityManager。 JPQL 查询有什么缺陷？ JPA 1.0 引进了 JPQL，这是一种强大的查询语言，它在很大程度上导致了 JPA 的流行。不过，基于字符串并使用有限语法的 JPQL 存在一些限制。要理解 JPQL 的主要限制之一，请查看清单 1 中的简单代码片段，它通过执行 JPQL 查询选择年龄大于 20 岁的 Person 列表： 清单 1. 一个简单（并且错误）的 JPQL 查询 EntityManager em = ...; String jpql = select p from Person where p.age 20; Query query = em.createQuery(jpql); List result = query.getResultList(); 这个基础的例子显示了 JPA 1.0 中的查询执行模型的以下关键方面： JPQL 查询被指定为一个 String（第 2 行）。 EntityManager 是构造一个包含给定 JPQL 字符串的可执行 查询实例的工厂（第 3 行）。 查询执行的结果包含无类型的 java.util.List 的元素。 但是这个简单的例子有一个验证的错误。该代码能够顺利通过编译，但将在运行时失败，因为该 JPQL 查询字符串的语法有误。清单 1 的第 2 行的正确语法为： String jpql = select p from Person p where p.age 20; 不幸的是，Java 编译器不能发现此类错误。在运行时，该错误将出现在第 3 或第 4 行（具体行数取决于 JPA 提供者是否在查询构造或执行期间根据 JPQL 语法解析 JPQL 字符串）。 类型安全查询如何提供帮助？ Criteria API 的最大优势之一就是禁止构造语法错误的查询。清单 2 使用 CriteriaQuery 接口重新编写了 清单 1 中的 JPQL 查询： 清单 2. 编写 CriteriaQuery 的基本步骤 EntityManager em = ... QueryBuilder qb = em.getQueryBuilder(); CriteriaQuery Person c = qb.createQuery(Person.class); Root Person p = c.from(Person.class); Predicate condition = qb.gt(p.get(Person_.age), 20); c.where(condition); TypedQuery Person q = em.createQuery(c); List Person result = q.getResultList(); 清单 2 展示了 Criteria API 的核心构造及其基本使用： 第 1 行通过几种可用方法之一获取一个 EntityManager 实例。 在第 2 行，EntityManager 创建 QueryBuilder 的一个实例。QueryBuilder 是 CriteriaQuery 的工厂。 在第 3 行，QueryBuilder 工厂构造一个 CriteriaQuery 实例。CriteriaQuery 被赋予泛型类型。泛型参数声明 CriteriaQuery 在执行时返回的结果的类型。在构造 CriteriaQuery 时，您可以提供各种结果类型参数 —— 从持久化实