JPA 2.0 中的动态类型安全查询

核心提示： QueryBuilder 是 CriteriaQuery 和各种查询表达式的工厂，CriteriaQuery 被传递给一个可执行查询并保留类型信息，JPA 2.0 中的动态类型安全查询(6)，这样可以直接访问选择列表的元素，而不需要任何运行时强制类型转换，如果该代码包含任何错误输入，它在运行时肯

QueryBuilder 是 CriteriaQuery 和各种查询表达式的工厂。

CriteriaQuery 被传递给一个可执行查询并保留类型信息，这样可以直接访问选择列表的元素，而不需要任何运行时强制类型转换。

持久化域的元模型

讨论 清单 2 时指出了一个不常见的构造：Person_.age，它表示 Person 的持久化属性 age。清单 2 使用 Person_.age 形成一个路径表达式，它通过 p.get(Person_.age) 从 Root<Person> 表达式 p 导航而来。Person_.age 是 Person_ 类中的公共静态字段，Person_ 是静态、已实例化的规范元模型类，对应于原来的 Person 实体类。

元模型类描述持久化类的元数据。如果一个类安装 JPA 2.0 规范精确地描述持久化实体的元数据，那么该元模型类就是规范的。规范的元模型类是静态的，因此它的所有成员变量都被声明为静态的（也是 public 的）。Person_.age 是静态成员变量之一。您可以在开发时在源代码中生成一个具体的 Person_.java 来实例化 一个规范类。实例化之后，它就可以在编译期间以强类型的方式引用 Person 的持久化属性。

这个 Person_metamodel 类是引用 Person 的元信息的一种代替方法。这种方法类似于经常使用（有人可能认为是滥用）的 Java Reflection API，但概念上有很大的不同。您可以使用反射获得关于 java.lang.Class 的实例的元信息，但是不能以编译器能够检查的方式引用关于 Person.class 的元信息。例如，使用反射时，您将这样引用 Person.class 中的 age 字段：

Field　field　=　Person.class.getField("age");　

不过，这种方法也存在很大的限制，类似于 清单 1 中基于字符串的 JPQL 查询存在的限制。编译器能够顺利编译该代码，但不能确定它是否可以正常工作。如果该代码包含任何错误输入，它在运行时肯定会失败。反射不能实现 JPA 2.0 的类型安全查询 API 要实现的功能。