在可能的情况下,是否应该删除SQL查询以支持使用Hibernate？

Question

阅读了Hibernate的理论后,我多次遇到这样的想法,在理想的世界中,你不应该将Hibernate与原始的SQL查询混合在一起,原因有多种,比如Hibernate无法识别以这种方式执行的更改在正确冲洗方面有影响.

我的任务是尝试优化和改进与数据库通信的几个类,但不经过Hibernate就这样做.他们直接使用JdbcTemplate来运行查询,我注意到这对更新语句更常见.

这是故意和良好的设计,由于某些原因,例如只更新选定数量的字段并且数据库中的对象非常大,或者我是否应该重构这些类以便它们利用DAO层类来执行这些更新疑问？

Answer 1

就我个人而言，在使用 hibernate 几年后（我对 hibernate 的喜爱多于讨厌），我发现当您只想进行 hibernate查询时有两个主要原因。可能转移到不同的数据库，查询缓存将是另一个问题。对我来说，如果这对你很重要的话，这两个理由都是非常合理的。您可能会在这里得到更多答案，为什么这是一件好事，所以我不会告诉您更多相关信息。相反，我可能会告诉你为什么在我实际遇到的案例中这并不总是可能的。

空间查询——几何和地理数据类型；有很多数据库支持这一点，有时这是一个非常方便的功能 - 我真的很喜欢 MSSQL 在这方面，他们的索引策略，如何处理等等。没有办法在 hibernate 中进行这些查询，这非常有帮助。为此的设施有限。

Hibernate 有时会隐藏更多它应该隐藏的内容（这不是它的错）；如果您不了解 hibernate 将生成哪些查询，您可能会经常感到非常惊讶。我建议您始终检查实际查询。另一个例子是，当您使用悲观/乐观锁时 -始终查看查询，hibernate 并不总是会生成您期望的结果......（AzureSQL 没有select for update- 它使用hints，像with row lock等 - 给你零确保一行将被锁定，如果没有适当的索引和很少的资源，整个表或页面可能会被锁定）

话虽这么说，在这方面我总是尝试支持 Hibernate，如果某些事情没有按我的预期工作 - 我使用本机查询，恕我直言，这个完美形状的世界根本不存在。