使用Criteria或HQL的优点和缺点是什么?Criteria API是一种在Hibernate中表达查询的面向对象的好方法,但有时Criteria queries比HQL更难理解/构建。
什么时候使用标准,什么时候使用HQL?在哪些用例中您更喜欢什么?还是说这只是个人口味的问题?
使用Criteria或HQL的优点和缺点是什么?Criteria API是一种在Hibernate中表达查询的面向对象的好方法,但有时Criteria queries比HQL更难理解/构建。
什么时候使用标准,什么时候使用HQL?在哪些用例中您更喜欢什么?还是说这只是个人口味的问题?
当前回答
这个帖子很老了。大多数答案谈论的是Hibernate标准,而不是JPA标准。JPA 2.1增加了CriteriaDelete/CriteriaUpdate和EntityGraph来控制获取什么。Criteria API更好,因为Java是面向对象的。这就是创建JPA的原因。当JPQL被编译时,它将被转换为AST树(OO模型),然后再转换为SQL。
其他回答
这里的大多数答案都是误导性的,并提到标准查询比HQL慢,但事实并非如此。
如果你深入研究并执行一些测试,你会发现标准查询比常规HQL执行得更好。
同样,通过Criteria Query,你可以得到HQL所没有的面向对象的控制。
更多信息请阅读这里的答案。
对于动态查询,我更喜欢使用条件查询。例如,根据某些参数,动态地添加一些排序或保留一些部分(例如限制)要容易得多。
另一方面,我使用HQL进行静态和复杂的查询,因为它更容易理解/阅读HQL。此外,我认为HQL更强大一些,例如对于不同的连接类型。
Criteria是一个面向对象的API,而HQL意味着字符串连接。这意味着面向对象的所有好处都适用:
All else being equal, the OO version is somewhat less prone to error. Any old string could get appended into the HQL query, whereas only valid Criteria objects can make it into a Criteria tree. Effectively, the Criteria classes are more constrained. With auto-complete, the OO is more discoverable (and thus easier to use, for me at least). You don't necessarily need to remember which parts of the query go where; the IDE can help you You also don't need to remember the particulars of the syntax (like which symbols go where). All you need to know is how to call methods and create objects.
由于HQL非常像SQL(大多数开发人员已经非常了解SQL),因此这些“不必记住”参数就没有那么重要了。如果HQL有更大的不同,那么这就更重要了。
标准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的替代品。
对于动态条件查询,我们可以根据我们的输入构造查询..在Hql查询是静态查询的情况下,一旦我们构造,我们就不能改变查询的结构。