3

我用 Hibernate 作为我的 JPA 实现做了很多工作。在大多数情况下，它工作正常！但我也看到了很多陷阱：

  • 使用持久对象进行远程处理很困难，因为 Hibernate 用自己的集合实现替换了 Java 集合。所以每个客户端都必须有 Hibernate .jar 库。您必须注意 LazyLoading 异常等。解决此问题的一种方法是使用 Web 服务。
  • 对数据库进行不带任何锁定的脏检查。
  • “延迟 SQL”，导致数据访问不符合 ACID。（丢失的数据...）
  • 隐式更新>>所以我们不知道对象是否被修改（提交导致更新）。

Toplink、Eclipse Link 和 Ibatis 是否存在类似问题？我应该什么时候使用它们？他们有类似的表现吗？是否有理由选择 Eclipse Link/Toplink... 而不是 Hibernate？

4

4 回答 4

5

我可以分享我相当数量的 Hibernate 陷阱：

  • Criteria API 不是类型安全的
  • Criteria API 的设计相对较差（例如：您无法检索当前别名）
  • 如果您创建别名，则强制进行内部连接（这在文档中但具有误导性）
  • 不支持 UNION
  • 没有简单的方法来“解除代理”持久对象（第三方支持远程处理）
  • 不支持没有 PK 的表（我现在很笨，但它发生在旧模式中）
  • 没有简单的方法使用非 PK 列的序列（不是那么愚蠢）

对于大多数 JPA 实现，我总是发现我必须依赖一些自定义注释来完成 JPA 规范中未涵盖的事情。

于 2009-04-09T15:06:58.397 回答
2

是否有理由选择 Eclipse Link/Toplink... 而不是 Hibernate？

在 O/R 映射器开发者领域（我住的地方；））Toplink 被认为是功能最完整和最好的 O/R 映射器，这是一个普遍的事实。它有它的弱点，但它的大量功能使其难以被击败。由于它现在是开源且免费的，我会尝试一下。

iBatis 并不是真正的 O/R 映射器，它更像是通过硬编码 SQL 实现的类填充/持久化。因此，您必须完成繁重的工作并且必须编写所有查询。当您使用带有存储过程的数据库并且必须利用这些过程进行 DML/集合检索时，iBatis 非常有用。

于 2009-04-13T11:14:32.997 回答
1

无法评论其他实现，但对于 DataNucleus AccessPlatform ...

  1. 远程处理可能需要存在“jdo.jar”，因为模型类是字节码增强的。或者，如果在远程端使用“只读”，则在那里使用未增强的类，并且所有工作都无需额外的 jar。
  2. 脏检查是通过字节码增强完成的，因此无需去数据存储区查看字段是否脏（当您想要访问数据存储区时，您可以控制锁）。显然，与基于反射的实现相比，这具有显着的性能优势。
  3. 我知道不可能有“丢失的更新”；使用乐观锁定会有所帮助。
  4. 由于“托管关系”，您可以获得隐式更新（您有一个双向关系并且您只更改一侧，因此 DataNucleus 将另一侧更新为一致......在flush（））。您可以关闭“托管关系”（在一定程度上）。您可以轻松启用对象的版本控制并了解对象是否被修改。

此处记录了选择 DataNucleus 的原因

高温高压

——Andy DataNucleus

于 2009-04-06T13:22:05.457 回答
1

关于 Ebean ORM http://www.avaje.org和您的陷阱：

远程处理

您可以在查询中使用“vanilla”模式，然后 Ebean 将返回普通 bean 和集合。这仅在您使用“动态代理/动态子类”时有效，但在您使用增强功能时无效（因为实体 bean 类明显增强）。

对数据库进行不带任何锁的脏检查。

我相信你的意思是乐观并发检查？如果是这样，那么根据定义，它是在没有显式数据库锁的情况下完成的。如果您想要/需要数据库锁（选择更新等），则需要使用悲观锁定 - 所以我不理解您的观点。

延迟的 SQL

Ebean 没有会话，因此它没有会话 flush()。当您使用 JDBC 批处理时，SQL 仍然可以通过 Ebean 延迟，但它与使用 session flush() 获得的延迟不同。

隐式更新

我们从前 Hibernate 和前 JPA 人员那里听到的常见抱怨。Ebean 的架构没有会话/实体管理器。相反，您需要显式地 save() 一个 bean 或将其级联到相关的 bean。所以是的，Ebean 没有隐式更新。

于 2010-05-06T01:04:23.817 回答