陷阱和实际用例：Toplink、Hibernate、Eclipse Link、Ibatis

Question

我经常使用 Hibernate 作为我的 JPA 实现。 大多数情况下它工作得很好！ 但我也看到了很多陷阱：

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

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

Answer 1

我可以分享我的大量 Hibernate 陷阱：

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

对于大多数 JPA 实现，我总是发现我必须依赖一些自定义注释或类似的东西来完成在JPA 规格

Answer 2

有什么理由选择Eclipse
Link/Toplink...通过 Hibernate？

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

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

Answer 3

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

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

选择 DataNucleus 的原因记录在此处

HTH

--Andy DataNucleus

Answer 4

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

远程处理

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

脏检查是在没有任何锁定的情况下对数据库进行的。

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

延迟SQL

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

隐式更新 这

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