对我来说，Criteria是一个很容易理解的动态查询。但我说到目前为止的缺陷是，它加载所有的多-一等关系，因为我们只有三种类型的FetchModes，即选择，代理和默认，在所有这些情况下，它加载多-一(可能是我错了，如果这样帮助我:))

第二个问题与标准是，它加载完整的对象，即，如果我想只是加载一个员工的EmpName，它不会提出这个，而是提出完整的员工对象，我可以从它得到EmpName，因为这真的工作不好的报告。因为HQL只是加载(没有加载关联/关系)你想要的，所以性能会提高很多倍。

Criteria的一个特点是，它将使你免受SQL注入的伤害，因为它的动态查询生成，而在HQL中，ur的查询要么是固定的，要么是参数化的，因此在SQL注入中不安全。

同样，如果你在你的aspx.cs文件中编写HQL，那么你与你的DAL紧密耦合。

总的来说，我的结论是，有些地方你不能没有HQL，比如报告，所以使用它们，否则Criteria更容易管理。

另一点是，我认为Criteria更适合在它的基础上构建，而不是在最终代码中直接使用。

它更适合使用它来构建库，而不是使用jpql或hql。

例如，我使用Criteria API构建了spring-data-jpa-mongodb-expressions(与spring数据QBE的方式相同)。

我认为spring数据查询代使用jpaql而不是标准，我不明白为什么。

HQL更容易阅读，更容易使用Eclipse Hibernate插件等工具进行调试，也更容易记录日志。条件查询更适合构建动态查询，其中许多行为都是在运行时确定的。如果你不知道SQL，我可以理解使用Criteria查询，但总的来说，如果我知道我想要什么，我更喜欢HQL。

HQL可能会导致SQL注入等安全问题。

标准API

Criteria API更适合动态生成查询。因此，如果您想添加WHERE子句过滤器、JOIN子句，或者改变ORDER BY子句或投影列，Criteria API可以帮助您以一种防止SQL注入攻击的方式动态生成查询。

另一方面，Criteria查询表达能力较差，甚至可能导致非常复杂和低效的SQL查询。

JPQL和HQL

JPQL是JPA标准实体查询语言，而HQL扩展了JPQL并添加了一些特定于hibernate的特性。

JPQL和HQL非常具有表现力，并且类似于SQL。与Criteria API不同，JPQL和HQL可以很容易地预测JPA提供者生成的底层SQL查询。复查HQL查询也比Criteria查询容易得多。

值得注意的是，如果需要修改实体，选择使用JPQL或Criteria API的实体是有意义的。否则，DTO投影是更好的选择。

结论

如果不需要改变实体查询结构，则使用JPQL或HQL。如果需要更改过滤或排序标准或更改投影，则使用criteria API。

然而，仅仅因为您正在使用JPA或Hibernate，这并不意味着您不应该使用本机SQL。SQL查询非常有用，JPQL和Criteria API不是SQL的替代品。

当我不知道哪些输入将用于哪些数据时，我通常使用Criteria。就像在一个搜索表单上，用户可以输入1到50个项目中的任何一个，我不知道他们会搜索什么。在检查用户正在搜索的内容时，很容易将更多内容添加到条件中。我认为在这种情况下放置HQL查询会更麻烦一些。当我确切地知道我想要什么时，HQL是很棒的。