为什么Hibernate开放会话在View中被认为是一种糟糕的实践？

Question

为什么Hibernate开放会话在View中被认为是一种糟糕的实践？您使用了什么样的替代策略来避免LazyLoadExceptions？我理解公开会议存在以下问题：在不同JVM中运行的分层应用程序事务只在结束时提交，很可能您希望得到之前的结果。但是，如果您知道您的应用程序运行在单个VM上，那么为什么不使用视图中的开放会话策略来减轻您的痛苦呢

Answer 1

因为在视图层中发送可能未初始化的代理，特别是集合，并从视图层触发Hibernate加载，可能会从性能和理解的角度引起麻烦。

理解:

使用OSIV“污染”视图层，与数据访问层有关。

视图层不准备处理HibernateException这种情况可能发生在延迟加载时，但据推测数据访问层是。

性能:

OSIV倾向于将合适的实体加载到地毯下-您往往不会注意到您的集合或实体是惰性初始化的(可能是N+1)。更方便，更少控制。

---

最新情况：看见OpenSessionInView反模式就这个问题进行更广泛的讨论。作者列举了三个要点：

1. 每次延迟初始化都会得到一个查询，这意味着每个实体都需要N+1查询，其中N是延迟关联的数量。如果您的屏幕显示表格数据，读取Hibernate的日志是一个很大的提示，表明您没有按照您应该做的那样做
2. 这完全违背了分层架构，因为您在表示层中用DB玷污了您的指甲。这是一个概念上的骗局，所以我可以接受它，但也有一个必然结果。
3. 最后但并非最不重要的一点是，如果在获取会话时发生异常，则在编写页面时会发生异常：您不能向用户显示一个干净的错误页，您唯一能做的就是在正文中写入错误消息。

Answer 2

• 事务可以在服务层中提交-事务与OSIV无关。是因为Session保持开放，而不是交易运行。

• 如果您的应用程序层分布在多台计算机上，那么您的不能使用OSIV-在通过线路发送对象之前，必须初始化所需的一切。

• OSIV是一种很好且透明的方法(也就是说，您的代码都不知道会发生这种情况)，它可以利用延迟加载的性能优势。