什么时候可以/应该全力使用 ORM 方法？

Question

在我看来，引入 ORM 工具应该会让您的架构更加清晰，但为了提高效率，我发现自己有时会绕过它并迭代 JDBC 结果集。这导致了不协调的工件混乱，而不是更干净的架构。

这是因为我在无效的上下文中应用该工具，还是比这更深入？

什么时候可以/应该全力使用 ORM 方法？

任何见解将不胜感激。

---

一些背景：

在我的环境中，我有大约 50 台客户端计算机和 1 台相当强大的 SQL Server。

我有一个桌面应用程序，其中所有 50 个客户端始终都在访问数据。

由于清晰度、效率等各种原因，该项目的数据模型经历了多次重组。

我的数据模型的历史

1. JDBC直接调用
2. DAO + POJO，Pojo 之间没有关系（基本上包装了 JDBC）。
3. 添加了实现延迟加载的 POJO 之间的关系，但只是隐藏了 DAO 间调用
4. 在看到 Hibernate 使数据访问变得多么“简单”（它使 POJO 之间的关系变得微不足道）并且因为它可以减少与许多相关实体一起工作时到数据库的往返次数后，我加入了 Hibernate 潮流。
5. 由于它是一个桌面应用程序，保持会话长期打开是一场噩梦，因此它最终导致了很多问题
6. 回到部分 DAO/Hibernate 方法，该方法允许我在 DAO 幕后进行直接 JDBC 调用，同时使用 Hibernate。

Answer 1

当您的应用程序运行时，Hibernate 更有意义 对象图, ，它们保存在 RDBMS 中。相反，如果您的应用程序逻辑适用于二维数据矩阵，那么通过直接 JDBC 获取这些数据效果会更好。尽管 Hibernate 是在 JDBC 之上编写的，但它具有在 JDBC 中实现起来可能并不简单的功能。例如：

1. 假设用户在 UI 中查看一行并更改了一些值，并且您希望仅针对那些确实发生更改的列触发更新查询。
2. 为了避免陷入死锁，您需要在事务中维护 SQL 的全局顺序。获得正确的 JDBC 可能并不容易
3. 轻松设置乐观锁定。当您使用 JDBC 时，您需要记住在每个更新查询中都包含此内容。
4. 在 JDBC 中实现批量更新、集合的惰性具体化等可能也很重要。

（我说 ”可能 是不平凡的”，因为它当然可以做到 - 而且你可能是一个超级黑客:)

如果需要，Hibernate 还允许您触发自己的 SQL 查询。

希望这可以帮助您做出决定。

附：在远程桌面客户端上保持会话打开并遇到麻烦实际上不是 Hibernate 的问题 - 如果长时间保持与数据库的连接打开，您也会遇到同样的问题。