在我看来，引入ORM工具应该可以使体系结构更整洁，但是为了提高效率，我发现自己绕过了它，有时会遍历JDBC结果集。这导致了工件的不协调纠缠，而不是更清洁的体系结构。

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

什么时候可以/应该完全采用ORM方法？

任何见识将不胜感激。

一些背景：

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

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

由于各种原因，包括清晰，高效等，该项目的数据模型已经进行了许多重组。

我的数据模型的历史

• JDBC直接调用
• DAO + POJO之间没有Pojos之间的关系(基本上包装了JDBC)。
• 在实现延迟加载的POJO之间添加了关系，但只是隐藏了DAO间的调用
• 在看到它如何"简单"地进行数据访问(使POJO之间的关系变得微不足道)并且因为与许多相关实体一起工作可以减少往返数据库的次数之后，跳入了Hibernate的行列。
• 由于它是一个桌面应用程序，因此长期保持Sessions的开放是一场噩梦，因此最终导致了很多问题
• 回到部分DAO / Hibernate方法，该方法允许我在DAO幕后进行直接JDBC调用，同时使用Hibernate。

解决方案

回答

当应用程序在RDBMS中持久保存的对象图上工作时，Hibernate更有意义。相反，如果应用程序逻辑适用于二维数据矩阵，则通过直接JDBC来获取数据的效果更好。尽管Hibernate是在JDBC之上编写的，但它具有的功能对于在JDBC中实现来说可能并非易事。例如：

• 假设用户查看了UI中的一行并更改了一些值，而我们只想对确实发生更改的那些列触发更新查询。
• 为了避免陷入僵局，我们需要在事务中维护SQL的全局顺序。获得正确的JDBC可能并不容易
• 轻松设置乐观锁定。使用JDBC时，需要记住在每个更新查询中都具有​​此功能。
• 在JDBC中实现批处理更新，集合的延迟实现等也是不容易的。

(我说"可能不简单"，因为它当然可以做到，而且我们可能是超级黑客：)

Hibernate还允许我们在需要时触发自己的SQL查询。

希望这可以做出决定。

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