ORM延迟加载有什么好处？

Question

我正在研究基于网络的新报告系统的数据层基础,并且在过去几天里花了很多时间来评估ORM.也就是说,我之前从未处理过"延迟加载",并且对于为什么它是实体框架中LINQ查询的默认设置感到困惑.它似乎会创建大量的网络流量,并且不必要地使用其他查询对数据库执行任务,否则可以使用联接来解析这些查询.

有人可以描述延迟加载会有益的场景吗？

一些元:

新系统将在生产环境中针对数百个表和数TB数据的数据库进行工作,系统中每天24小时有超过3,000个并发用户.他们将连续检索大型数据集.ORM是否可能不是满足我们需求的正确解决方案,特别是因为应用程序将基于网络？

Answer 1

当我们谈论延迟加载时,我们讨论的是导航属性(我们如何遵循外键).延迟加载将为我们做的是在我们尝试访问该实体时从远程表填充实体.例如,如果我们有这样的模型

public class TestEntity
{
    public int Id{get;set;}
    public AnotherEntity RemoteEntity{get;set;}
}

并致电以下内容

var something = WhateverContext.TestEntities.First().RemoteEntity;

我们将获得2个数据库调用,WhateverContext.TestEntities.First()一个用于加载,一个用于加载远程实体.

我是一个网络人,(更具体地说是一个MVC人)和网络内容我认为没有理由这么做,如果我们需要,一个数据库调用总是比两个快.同一组数据.

我认为延迟加载实际上值得考虑的情况是,如果您根本不需要第二个实体,那么当您不知道何时进行第一次查询时.在我看来,这与我们有一个实时执行操作的用户的Windows应用程序更相关(而不是用户一次请求整个页面的无状态MVC).例如,当我们有一个带有详细信息链接的数据列表时,我认为延迟加载会闪耀,然后我们不会加载细节,直到用户决定要查看它们为止.

我觉得这不会扩展到分页,排序和过滤,IMO应该有一个专门设计的数据库查询每页显示的数据,它会返回显示该页面所需的数据集.

就您的性能问题而言,我觉得EF(或其他ORM)可能在这里可以满足您的需求,但您要小心如何检索大型数据集,因为EF跟踪实体的方式.查看我的EF性能调整备忘单,如果您决定在大型查询中使用EF,请阅读DetectChanges和AsNoTracking.