Hibernate延迟加载应用程序设计

Question

我倾向于将Hibernate与Spring框架结合使用，它具有声明式事务划分功能（例如@Transactional）。

众所周知，hibernate试图尽可能做到 非侵入性 和 透明性 ，但是事实证明，在使用关系时这 更具挑战性 lazy-loaded 。

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

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

我错过了任何选择吗？

尝试最小化lazy-loaded关系对应用程序设计的影响时，您首选的方法是什么？

（哦，对不起，WOT）

Answer 1

众所周知，hibernate试图尽可能做到无创且透明

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

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

从这个角度来看，明确表达这些意图（即2、4和7）的解决方案看起来是合理的，并且不会遭受缺乏透明度的困扰。