使用Criteria或HQL的优点和缺点是什么?Criteria API是一种在Hibernate中表达查询的面向对象的好方法,但有时Criteria queries比HQL更难理解/构建。

什么时候使用标准,什么时候使用HQL?在哪些用例中您更喜欢什么?还是说这只是个人口味的问题?


当前回答

HQL is to perform both select and non-select operations on the data, but Criteria is only for selecting the data, we cannot perform non-select operations using criteria HQL is suitable for executing Static Queries, where as Criteria is suitable for executing Dynamic Queries HQL doesn’t support pagination concept, but we can achieve pagination with Criteria Criteria used to take more time to execute then HQL With Criteria we are safe with SQL Injection because of its dynamic query generation but in HQL as your queries are either fixed or parametrized, there is no safe from SQL Injection.

其他回答

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

这里的大多数答案都是误导性的,并提到标准查询比HQL慢,但事实并非如此。

如果你深入研究并执行一些测试,你会发现标准查询比常规HQL执行得更好。

同样,通过Criteria Query,你可以得到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和criteriaQuery在性能上是有区别的,每次你使用criteriaQuery发起查询时,它会为表名创建一个新的别名,这个别名不会反映在任何DB的最后一个查询缓存中。这会导致编译生成的SQL的开销,需要更多的时间来执行。

关于抓取策略[http://www.hibernate.org/315.html]

Criteria respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one Criteria query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what", use setFetchMode() to enable or disable outer join fetching for a particular collection or association. Criteria queries also completely respect the fetching strategy (join vs select vs subselect). HQL respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one HQL query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what", use LEFT JOIN FETCH to enable outer-join fetching for a particular collection or nullable many-to-one or one-to-one association, or JOIN FETCH to enable inner join fetching for a non-nullable many-to-one or one-to-one association. HQL queries do not respect any fetch="join" defined in the mapping document.

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