【问题标题】:Understanding EF Code-First eager-loading了解 EF Code-First 急切加载
【发布时间】:2012-11-12 15:10:44
【问题描述】:

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

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

  • 在什么情况下我应该禁用延迟加载?为什么?
  • 禁用它有哪些实际好处和/或缺点?
  • 欢迎任何其他澄清。

【问题讨论】:

    标签: entity-framework ef-code-first lazy-loading eager-loading


    【解决方案1】:

    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-us/magazine/hh205756.aspx

    【讨论】:

    • 过滤的 DbSet 怎么样?急切/延迟加载是否在其中起任何作用?
    • 我不确定您所说的过滤 DbSet 是什么。对导航属性进行延迟加载。
    猜你喜欢
    • 2012-08-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多