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

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


当前回答

我不想在这里白费口舌,但有一点很重要,那就是Criteria查询现在已被弃用。使用HQL。

其他回答

为了两全其美,HQL的表达性和简洁性以及Criteria的动态特性可以考虑使用Querydsl。

Querydsl支持JPA/Hibernate, JDO, SQL和Collections。

我是Querydsl的维护者,所以这个答案是有偏见的。

还有另一种方法。我最终创建了一个基于hibernate原始语法的HQL解析器,这样它就可以首先解析HQL,然后动态地注入动态参数或自动为HQL查询添加一些通用过滤器。效果很好!

对我来说,Criteria最大的优势是示例API,在这里你可以传递一个对象,hibernate将基于这些对象属性构建一个查询。

除此之外,标准API也有它的怪癖(我相信hibernate团队正在重做API),比如:

a criteria.createAlias("obj")强制使用内部连接而不是可能的外部连接 您不能两次创建相同的别名 有些SQL子句没有简单的对应条件(比如子选择) 等。

当我想要类似于sql的查询时,我倾向于使用HQL(从用户中删除status='blocked'),当我不想使用字符串追加时,我倾向于使用标准。

HQL的另一个优点是您可以预先定义所有的查询,甚至可以将它们外部化到一个文件中。

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

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

同样,通过Criteria Query,你可以得到HQL所没有的面向对象的控制。

更多信息请阅读这里的答案。

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