JPA 2.0中的动态类型安全查询 - 编程入门网
JPA 2.0中的动态类型安全查询时间:2011-02-03 IBM Pinaki Poddar自从 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 查询
这个基础的例子显示了 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 的基本步骤
JPA 2.0中的动态类型安全查询(2)时间:2011-02-03 IBM Pinaki Poddar清单 2 展示了 Criteria API 的核心构造及其基本使用: 第 1 行通过几种可用方法之一获取一个 EntityManager 实例。 在第 2 行,EntityManager 创建 QueryBuilder 的一个实例。QueryBuilder 是 CriteriaQuery 的工厂。 在第 3 行,QueryBuilder 工厂构造一个 CriteriaQuery 实例。CriteriaQuery 被赋予泛型类型。泛型参数声明 CriteriaQuery 在执行时返回的结果的类型。在构造 CriteriaQuery 时 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |