1

自从 EF 4.1 上线以来，我一直在使用 EF CodeFirst，那是一年多以前的事了，现在使用它感觉很舒服。我习惯于自定义实体验证器，重写 .SaveChanges() 来修改它的一些行为以及一些重要的概念，比如映射到非表数据库对象。但是 EF 的这一部分对我来说仍然是多云的：context.Configuration.LazyLoadingEnabled = false;。

我了解基础知识，一旦调用 linq 查询，它们就会被扔到数据库中，如果我没有明确指定它，将不会加载依赖集合，yadda yadda yadda。我想了解的是：

  • 在什么情况下我应该禁用延迟加载？为什么？
  • 禁用它的实际好处和/或缺点是什么？
  • 欢迎任何额外的澄清。
4

1 回答 1

0

EF v1 不支持延迟加载。当在第二轮中添加延迟加载（它是 EF4）时，将使用 EF v1 编写的应用程序移植到 EF4 时可能会导致问题，因为以前没有发生过的情况会突然向数据库发送更多查询。因此，使 EF v1 在 EF4 上运行的最简单方法是禁用延迟加载。

另一个有趣的事情是看看延迟加载是如何实现的——EF 会动态地创建一个从你的实体类型派生的类型，并且会添加一些代码来处理延迟加载。这意味着 EF 实际上并没有使用您的类型，而是使用从您的类型派生的类型。这通常没问题，但有时可能会导致问题。

最后，有时您可能想要控制查询实际发送到数据库的时间（例如，由于使用 Sql Azure 时的延迟，发送一个返回较大结果的查询而不是许多返回较小结果的查询通常更好/更快）。通过延迟加载，人们经常没有意识到他们在不必要或无效时对数据库进行了重创。这里要注意的一件事是，您可以混合使用这两个世界 - .Include() 将强制加载相关实体，而不管延迟加载设置如何。

您可以在此处阅读有关此内容的更多信息： http: //thedatafarm.com/blog/data-access/a-look-at-lazy-loading-in-ef4/和此处：http: //msdn.microsoft.com/en -我们/杂志/hh205756.aspx

于 2012-11-12T17:12:52.750 回答