JPA 2.0中的动态类型安全查询 - 编程入门网

现在归纳 清单 2 中的简单例子的基本方面：

CriteriaQuery 是一个查询表达式节点树。在传统的基于字符串的查询语言中，这些表达式节点用于指定查询子句，比如 FROM、WHERE 和 ORDER BY。图 2 显示了与查询相关的子句：

图 2. CriteriaQuery 封装了传统查询的子句

查询表达式被赋予泛型。一些典型的表达式是：

Root<T>，相当于一个 FROM 子句。

Predicate，其计算为布尔值 true 或 false（事实上，它被声明为 interface Predicate extends Expression<Boolean>）。

Path<T>，表示从 Root<?> 表达式导航到的持久化属性。Root<T> 是一个没有父类的特殊 Path<T>。

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

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

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

持久化域的元模型

讨论 清单 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 要实现的功能。

类型安全查询 API 必须让您的代码能够引用 Person 类中的持久化属性 age，同时让编译器能够在编译期间检查错误。JPA 2.0 提供的解决办法通过静态地公开相同的持久化属性实例化名为 Person_ 的元模型类（对应于 Person）。

关于元信息的讨论通常都是令人昏昏欲睡的。所以我将为熟悉的 Plain Old Java Object (POJO) 实体类展示一个具体的元模型类例子（domain.Person），如清单 3 所示：

清单 3. 一个简单的持久化实体

package　domain; @Entity public　class　Person　{ 　 @Id 　 private　long　ssn; 　 private　string　name; 　 private　int　age; 　 //　public　gettter/setter　methods 　 public　String　getName()　{...} }

这是 POJO 的典型定义，并且包含注释（比如 @Entity 或 @Id ），从而让 JPA 提供

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!