2

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

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

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

任何见解将不胜感激。

一点背景：

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

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

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

我的数据模型的历史

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

1 回答 1

4

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

  1. 比如说，用户在 UI 中查看了一行并更改了一些值，而您希望仅针对确实发生更改的那些列触发更新查询。
  2. 为避免陷入死锁，您需要维护事务中 SQL 的全局顺序。获得正确的 JDBC 可能并不容易
  3. 轻松设置乐观锁定。当你使用 JDBC 时，你需要记住在每个更新查询中都有这个。
  4. Batch updates, lazy materialization of collections etc might also be non-trivial to implement in JDBC.

(I say "might be non-trivial", because it of course can be done - and you might be a super hacker:)

Hibernate lets you fire your own SQL queries also, in case you need to.

Hope this helps you to decide.

PS: Keeping the Session open on a remote desktop client and running into trouble is really not Hibernate's problem - you would run into the same issue if you keep the Connection to the DB open for long.

于 2008-09-12T03:59:42.520 回答