java - Hibernate 延迟加载应用程序设计

Question

我倾向于使用 Hibernate结合 Spring框架和它的声明性事务划分功能(例如，@Transactional)。

众所周知，hibernate 尝试尽可能地非侵入性和透明，但这证明更具挑战性在使用 延迟加载 关系时。

---

我看到了许多具有不同透明度的设计替代方案。

1. 使关系不延迟加载(例如，fetchType=FetchType.EAGER)
   • 这违反了延迟加载的整个想法..
2. 使用 Hibernate.initialize(proxyObj); 初始化集合；
   • 这意味着与 DAO 的耦合度相对较高
   • 虽然我们可以使用 initialize 定义接口(interface)，但不保证其他实现提供任何等效项。
3. 将事务行为添加到持久 Model 对象本身(使用 dynamic proxy 或 @Transactional)
   • 我没有尝试过动态代理方法，尽管我似乎从来没有让@Transactional 处理持久对象本身。可能是由于 hibernate 是在代理上的操作。
   • 在交易实际发生时失去控制
4. 同时提供惰性/非惰性 API，例如 loadData() 和 loadDataWithDeps()
   • 强制应用知道何时使用哪个例程，再次紧耦合
   • 方法溢出，loadDataWithA(), ...., loadDataWithX()
5. 强制查找依赖项，例如，仅提供 byId() 操作
   • 需要很多非面向对象的例程，例如 findZzzById(zid)，然后是 getYyyIds(zid) 而不是 z.getY()
   • 如果事务之间的处理开销很大，则一个接一个地获取集合中的每个对象会很有用。
6. 成为应用程序的一部分 @Transactional 而不仅仅是DAO
   • 嵌套事务的可能考虑因素
   • 需要适应事务管理的例程(例如，足够小)
   • 程序影响小，但可能会导致大量交易
7. 为DAO提供动态fetch profiles ，例如，loadData(id, fetchProfile);
   • 应用程序必须知道何时使用哪个配置文件
8. AoP 类型的事务，例如，拦截操作并在必要时执行事务
   • 需要字节码操作或使用代理
   • 执行交易时失去控制
   • 一如既往的黑魔法:)

我错过了任何选项吗？

---

在尝试将 lazy-loaded 关系在您的应用程序设计中的影响降至最低时，您首选哪种方法？

(哦，对不起 WoT)

Answer 1

As we all known, hibernate tries to be as non-invasive and as transparent as possible

我会说最初的假设是错误的。透明持久性是一个神话，因为应用程序总是应该注意实体生命周期和正在加载的对象图的大小。

请注意，Hibernate 无法读取想法，因此如果您知道特定操作需要一组特定的依赖项，则需要以某种方式向 Hibernate 表达您的意图。

从这个角度来看，明确表达这些意图的解决方案(即 2、4 和 7)看起来是合理的，并且不会因缺乏透明度而受到影响。