Criteria Api Vs QueryDsl Vs JPA 元模型答案

【问题标题】：Criteria Api Vs QueryDsl Vs JPA metamodelCriteria Api Vs QueryDsl Vs JPA 元模型
【发布时间】：2019-04-18 21:54:48
【问题描述】：

我对这三个概念有点困惑。

标准 API
查询 Dsl
Jpa 2.0 元模型

根据我的阅读，使用 QueryDsl 或 JPA 元模型的主要好处之一是类型安全。
但即使使用 Criteria API，我也可以实现类型安全。（我正在使用 JPA 和 eclipselink）

javax.persistence.EntityManager 有两个变种

public Query createQuery(String sqlString);   
public <T> TypedQuery<T> createQuery(CriteriaQuery<T> criteriaQuery);

我同意第一个版本，我将 sql 作为字符串传递，我没有得到类型安全。但是在第二个版本中，我得到了类型安全。或者我在这里错过了什么？有人可以用一个例子来解释一下使用标准是不是类型安全的。

QueryDsl 和 JPA 静态元模型有什么区别？

【问题讨论】：

您对类型安全标准查询是正确的，更多信息在这里：developer.ibm.com/articles/j-typesafejpa

标签： java jpa-2.0 criteria querydsl type-safety

【解决方案1】：

您可以在 Criteria API 中使用 JPA 元模型来确保类型安全，但与 QueryDSL 相比，Criteria api 相当复杂

【讨论】：

【解决方案2】：

JPA 提供三种基本类型的查询

查询用 JPQL 编写。它有 TypedQuery 和 NamedQuery 的子类型。
NativeQuery 用纯 SQL 编写。
Criteria API 查询以编程方式构建。它可以使用Jpa元模型来指定属性，使其更加安全。

这些方法中的每一种都有自己的优点/缺点，因此您将根据自己的需要选择一种。

QueryDSL 是一个比 JPA 的 Criteria API 更简单和直观（恕我直言）的库。

问题中使用的示例是 TypedQuery。它只是 Query 的子类型，它在事先知道返回类型时定义它，并删除可能的类型转换异常。这只是关于返回类型，查询本身仍然是用普通的JPQL字符串构建的，所以它不是类型安全的查询。另一方面，Criteria API 是类型安全的。我们以编程方式构建查询，并且我们知道实体属性的类型。

Criteria Api 可以与基于字符串的属性一起使用。您可能会误输入“dept”，然后会出现错误。

CriteriaQuery<Employee> query = cb.createQuery(Employee.class);
Root<Employee> employee = query.from(Employee.class);
 query.select(employee)
      .where(cb.equal(employee.get("dept"), "Admin"));

或者我们可以使用 Jpa 元模型 生成的元模型类来引用属性。您不能输入错误的部门，因为您只能使用来自 Employee 的现有属性名称。

Root<Employee> employee = query.from(Employee.class);
query.select(employee)
     .where(cb.equal(employee.get(Employee_.dept), "Admin"));

或者我们可以使用 QueryDSL：

QEmployee employee = QEmployee.employee;
query.from(employee).where(employee.dept.eq("Admin"))

【讨论】：