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

Question

在阅读了 Hibernate 的理论之后，我多次遇到这样的想法，即在理想的世界中，您不应该将 Hibernate 与原始 SQL 查询混合使用，原因有很多，例如 Hibernate 无法识别以这种方式执行的更改，这可以在正确冲洗时会产生影响。

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

这是故意的和好的设计，出于某种原因，例如只更新了选定数量的字段并且数据库中的对象非常大，还是我应该旨在重构这些类，以便它们利用 DAO 层类来执行这些更新查询？

Answer 1

使用 Hibernate with HQL(Hibernate Query Language) 而不是 Native Queries（或 Hibernate 而不是 JDBC）有很多好处，我说明了其中的 3 个：多数据库支持：如果您使用不同的数据库，这是一个要求，但在您的情况下，我们可以通过一个示例来阐明这一点。假设有一天您决定更改数据库引擎。如果您的应用程序完全基于 HQL，您只需要在您的休眠配置中切换一个参数，它将负责“重新处理”您的所有查询，因此它们与您的新数据库兼容。只是这个。Java 对象连接：您完全自定义了这个方面（Hibernate 无法识别以这种方式执行的更改，这可能会对正确刷新产生影响）。将您的类和字段直接连接到数据库可以让您更好地管理代码和数据库更改。如果您的类或其中的字段发生更改，编译器将检查是否一切正常（我的意思是休眠端）。如果你使用像 IntelliJ 这样强大的 ide，它会在另一个方向上工作：如果你删除或更改数据库中的一个字段，你的 ide 会警告你类中的某些内容是错误的（不是有效的列，无效的类型） ， 等等）。Chaching和安全功能：例如整体，sql注入。一个糟糕的书面查询会使您面临安全问题，但使用 hibernate 它将处理它。而且它还有一个强大的缓存系统......他会为你毫不费力地做的另一件事。希望这可以帮助

Answer 2

就个人而言，若干年后与休眠（爱很多比恨我帐幕），我看到，当你想冬眠两个主要的原因，只查询。可能转移到不同的数据库，查询的缓存将是另一个。对我来说，如果这对您很重要，那么两者都是非常有效的理由。你可能会在这里得到更多答案，为什么这是一件好事，所以我不会告诉你更多关于这个的信息。相反，我可能会告诉你为什么这在我实际遇到的情况下并不总是可行的。空间查询 - 几何和地理数据类型；有很多数据库支持这一点，有时它是一个非常方便的功能 - 在这方面我真的很喜欢 MSSQL，他们的索引策略，如何处理等等。没有办法在休眠中进行这些查询，这非常有限的设施。Hibernate 有时会隐藏更多它应该隐藏的东西（这不是它的错）；如果您不了解休眠会生成什么查询，您可能会经常感到非常惊讶。我建议您始终检查实际查询。另一个例子是，当您使用悲观/乐观锁时 -始终查看查询，并不总是如此 Hibernate 可能会生成您所期望的......（AzureSQL 没有select for update- 它使用hints, likewith row lock等 - 给你零确保一行将被锁定，如果没有适当的索引和很少的资源，整个表或页面都可能被锁定）话虽如此，在这方面，我总是尝试支持 Hibernate，如果某些事情不像我预期的那样工作 - 我使用本机查询，恕我直言，这个完美成形的世界根本不存在。