我理解这是具体应用的具体内容，但我只是想知道一般意见是什么，或者至少是一些个人经历。
我对“开放会话视图”模式感到厌恶，所以为了避免这种情况，我正在考虑简单地将所有内容小心取出，并在服务层中使用查询来获取更大的内容。
有没有人用过这个并后悔了？在视图层中是否有一些我不知道的延迟加载的优雅解决方案？
答案 0 :(得分：5)
延迟加载仅在您根本不打算使用有问题的数据时才有用（例如，仅显示客户列表，因此忽略嵌套的订单集），或者如果不确定是否用户希望查看有问题的数据（例如，在内存中列出客户列表，订单列表请求取决于将来的操作）。
如果您确定一次显示所有数据，则不需要延迟加载，只需要额外的查询。
答案 1 :(得分：3)
如果您有一个设计良好的架构和广泛映射到应用程序中其他实体的实体，则基本上需要延迟加载。这是一个非常基本的例子：
人实体将一对多映射推介
推介一对一人两次（推荐人和推荐人）
够简单吧？好吧，如果你在这两种关系中使用急切加载，你最终可能会对大多数情况下可能无法显示的数据进行大量的后续查询。
例如：
您的应用想要加载记录“ PersonA ”，此 PersonA 有3个推介记录，因为他提到了3个客户： PersonB ， PersonC ， PersonD 。
因此，如果你有Eager获取此关系，JPA将加载这3个人的记录。让我们说 PersonC 引用了10位客户，因为他喜欢你所销售的产品。现在，JPA也必须加载这10个客户，这也是因为需要加载。
你可以看到它的发展方向。如果这是一个延迟加载的关系，那么加载这一额外数据集的唯一时间就是你直接对它进行getReferrals（）调用。
我个人会避免创建其他方法来进行这些提取。它需要很多额外的代码工作，现在你需要以某种方式管理实体的状态以及是否需要额外加载。
如果您使用延迟加载，JPA可以轻松实现。只要做任何事情......（）调用你通常会在实体POJO上做，而JPA会做其余事。