你什么时候可以/应该全力以赴地使用 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. 因为它是一个桌面应用程序，让 Sessions 长期保持打开状态是一场噩梦，所以它最终导致了很多问题
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 查询，以备不时之需。

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

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