问您喜欢JPA 2.0的Criteria api吗？你会在框架中使用它吗？

EN

我只能提供一个有偏见的观点，因为我是Querydsl的维护者，但我认为Querydsl和Spring规范都已经足够成熟。它们都在JPA2之上提供了一个薄层，Querydsl为查询构造提供了一个流畅的DSL，为DAO/Repository构造提供了Spring数据模式。

Querydsl的表达能力与HQL/JPQL相当。

下面是一些JPA2Criteria查询及其Querydsl版本：http://source.mysema.com/forum/mvnforum/viewthread_thread,49

我们在我们的论坛中提供快速的bug修复周期和响应支持。Querydsl团队与Spring、DataNucleus和其他各方合作，以改善Java语言中类型安全查询的状态。

不，我不喜欢它，因为API缺乏可表达性和流畅性。是的，QueryDSL用更少的代码做同样的事情，而且更自然。出于这个原因，我们对JDO自己的类型安全查询API采取了相同的方法，将其与JPA Criteria https://datanucleus.wordpress.com/2010/11/09/jdo-typesafe-vs-jpa-criteria/进行了比较

我大量使用JPA criteria builder。我使用元模型，类型安全的变体，但这不是唯一的选择。如果您想将JPA与其他框架进行比较，请不要考虑需要生成元模型类的事实。对于相同的功能，您不需要这样做，只是为了获得额外的好处。不过，我不会回到任何非类型安全的方法。

当你习惯它的时候，它很容易使用，而且仍然很强大。

一个额外的好处:它是标准的。例如:来自不同组织的多位专家都同意这一点。规范的质量是确定的，而且它还在不断发展。您会得到多个实现(实际上，至少有两个实现在最流行的应用程序服务器中使用)。如果你采用一个随机的框架，你就不会得到这样的结果，它可能经得起时间的考验，也可能经得起时间的考验。

来自JPA2的一些示例：

Root<Person> personRoot = query.from(Person.class);
Path firstNamePath = personRoot.get(Person_.firstName);
Predicate firstNamePredicate = criteriaBuilder.equal(firstNamePath, "Roger");
query.where(firstNamePredicate);

您可以将所有这些都压缩到一行中，但我大多数情况下选择不这样做是为了获得100%清晰的代码和每行一条语句。