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

Question

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

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

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

Answer 1

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

• Criteria API不是typesafe
• Criteria API设计相对较差（例如：您无法检索当前别名）
• 如果您创建别名，则表示您正在强制进行内部联接（这是在文档中，但会产生误导）
• 不支持UNIONs
• 没有简单的方法'取消代理'持久对象（第三方支持远程处理）
• 不支持没有PK的表（我现在很愚蠢，但它发生在遗留模式中）
• 没有简单的方法可以将序列用于非PK列（不是那么愚蠢）

对于大多数JPA实现，我总是发现我必须依赖一些自定义注释，或者做一些JPA规范中没有涉及的内容。

Answer 2

  

是否有理由选择Eclipse   Link / Toplink ...通过Hibernate？

在O / R mapper开发者的土地上（我住的地方;））这是一个常见的事实，Toplink被认为是功能最齐全，性能最好的O / R映射器。它有它的弱点，但它的大量功能使它成为难以击败的东西。因为它现在是开源和免费的，我会试一试。

iBatis实际上不是一个O / R映射器，它更像是通过硬编码SQL的类填充/持久化。所以你要做繁重的工作并且必须编写所有查询。当您使用具有存储过程的数据库并且必须利用这些过程进行DML /集检索时，iBatis非常有用。

Answer 3

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

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

选择DataNucleus的原因是documented here

HTH

- 安迪DataNucleus

Answer 4

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

<强>远程处理

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

对数据库进行脏检查，没有任何锁定。

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

延迟SQL

Ebean没有会话，因此它没有会话flush（）。使用JDBC批处理时，SQL仍然可以使用Ebean延迟，但它与session flush（）的延迟不同。

隐式更新

我们从前Hibernate和前JPA人员那里听到的常见抱怨。 Ebean的架构没有session / entityManager。相反，您需要显式保存（）一个bean或将该级联连接到相关的bean。所以是的，没有Ebean的隐式更新。