延迟加载真的很糟糕吗？答案

【问题标题】：Is Lazy Loading really bad?延迟加载真的很糟糕吗？
【发布时间】：2010-01-28 14:57:43
【问题描述】：

我听说过很多关于延迟加载的性能问题，无论是在 NHibernate、Linq....

问题是 N+1 选择。例如，我想要所有帖子及其用户，在 foreach 我懒加载用户，我需要一个选择帖子，加上每个用户选择 N 个。

延迟加载：

1 - select ....from post
N - select ....from user

“好的”方法是加入：

1 - select .....from post inner join user on post.UserId = user.Id

但是看到EF生成的SQL，我意识到浪费了很多数据。假设所有帖子都是同一个用户。 Inner Join 将为每个帖子行带来所有用户列。

在性能方面，哪种方法最好？

【问题讨论】：

这是一个很好的问题——如何选择——但我认为答案很大程度上取决于数据。但是，我认为您会感到惊讶的是，多个查询通常比“数据浪费”更糟糕，因为返回的数据超出了您的需要。换句话说，在某些情况下延迟加载很好，但在“典型”应用程序中却很少。
您的答案还取决于您的 ORM，因为在 EF 中，要使用您的示例，这不是唯一的两个选项。
@Craig Stuntz 还有哪些选择？我正在使用 EF4
在 EF（任何版本）中，您可以显式加载、急切加载或项目。在 EF 4 中，您也可以延迟加载。恕我直言，投影通常是正确的选择，因为它允许使用任何其他选项都无法实现的事情。
@Craig Stuntz，急切加载是“Include()”方法，项目是“select { post, post.user}”，加载是这样的吗？ "context.LoadProperty(beveragesCategory, c => c.Products);"

标签： sql linq nhibernate entity-framework lazy-loading

【解决方案1】：

延迟加载既不好也不坏。请参阅此以获得更冗长的解释：

When should one avoid using NHibernate's lazy-loading feature?

一般来说，延迟加载对于 ORM 来说是一种很好的默认行为，但作为 ORM 用户，您需要注意何时覆盖默认值并急切地加载数据。分析应用程序的性能是决定是否使用延迟加载的最佳方式。谨防在过早优化上花费过多精力。

【讨论】：

我认为一般规则是 DBA 不喜欢它，而 Web 应用程序开发人员喜欢 :)

【解决方案2】：

延迟加载的问题在于知道它是什么以及它什么时候会咬你。您需要知道可以对数据库进行多少次潜在的访问，以及如何解决这个问题。我不认为LL是坏的。我只需要了解它的后果。

【讨论】：

【解决方案3】：

我的大多数应用程序都涉及服务边界（Web 服务、WCF 等），此时在 OR/M 上的延迟加载毫无意义，在位于服务之上的实体中实现延迟加载有点像一个坏主意（实体现在必须知道该服务）。

【讨论】：

【解决方案4】：

延迟加载没有好坏之分。您必须决定是喜欢在运行时加载资源还是在应用程序加载时加载资源。例如 - 实时通常使用缓冲区来避免在运行时分配资源。这与延迟加载相反，有利于实时软件。

如果您的应用程序运行时间很长，并且您不想在启动时分配资源，那么延迟加载非常有用。

【讨论】：

【解决方案5】：

旧线程，但搜索出现了，所以我加了两分钱。除了必须意识到潜在的性能问题之外，在处理数据上下文后访问字段的问题使我现在无法使用 LL。如果您从创建和处理数据上下文的方法返回实体的实例，这就是它们的设计使用方式，访问这些虚拟字段将出现异常错误。对此的解决方案是在查询中包含字段（即 .Include），永远不要从您的数据层/服务返回实体类，或者让数据上下文保持更长时间。包含字段是最好的选择，而且在不启用延迟加载的情况下同样简单。

【讨论】：