EF使用延迟加载的本质原因

EF（Entity Framework）是微软的一个ORM框架

使用过EF的同学都知道它有一个延迟加载的功能

那么这个延迟加载的功能到底是什么？

为什么需要延迟加载？

使用延迟加载的优点和缺点又各是什么？

可以通过一个简单的小例子来阐述EF的这些问题

首先使用到了两个很简单的数据表

关系图如下：

T_Product的Uid关联到T_Users的Id，形成一个外键关系

是不是真的很简单= =

然后在测试项目中根据数据库添加EF数据模型

准备工作已经做好了，现在进入主题

首先需要搞明白的是：什么是延迟加载？

延迟加载又可以理解成 按需加载

根据字面的意思很容易理解：按照所需的数据 加载数据

上例子：

很简单的代码，相信大家都看得懂

接下来设置断点对代码的执行步骤进行分解

首先我在如图所示的位置设置了一个断点

打开sql server profiler监听接收到的sql语句

运行程序并命中断点

此时程序停留在到数据库取数据（姑且这么认为）的这行代码上

由于代码还未执行所以数据库不可能接收到任何的sql语句

按下F11逐语句执行

可以看到，程序跳转，数据库接收到sql语句

正是var user = dbEntities.T_Users.Where(u => u.Id == 2).FirstOrDefault();这行代码发送了sql语句到数据库取的数据

那么所谓的延迟加载体现在哪里呢？

其实这行代码是变相的即使加载，看起来像是调用where方法之后马上到数据库取出了数据，但是别忽略了后面的FirstOrDefault()

在EF中，调用where方法只是先保存了sql语句，但是并没有提交到数据库

但是当调用了FirstOrDefault()方法的时候就表示程序要用数据了，这时sql语句才会被提交到数据库中

这就是延迟加载，到要使用数据的时候才取出数据

口说无凭，下面继续用代码来证明这个说法

将代码拆分如下，还是在调用where方法的地方设置断点并运行

F11下一步

这时可以看到，代码已经执行了where方法，并停在了.FirstOrDefault方法，但是此时数据库并没有接收到任何sql语句

为了方便看清楚，在Console.ReadKey()也设置了一个断点，F5代码停留在Console.ReadKey()

现在已经很明显了，只有程序中要使用数据的时候（调用了FirstOrDefault），sql语句才会被发送发数据库

这就是EF的延迟加载

但是List集合本身就有一个where方法

难道这个where方法要是延迟加载的吗，但是这并不是到数据库取数据的呀

在上图的智能提示中可以隐约的看到，该where方法的第一个参数是一个IEnumerable的linq表达式

我们可以在var user = dbEntities.T_Users.Where(u => u.Id == 2)这行代码上对where方法按F12转到定义看一看

注意看一下这个where方法的返回值类型，是IQueryable而不是IEnumerable

这说明了两个where方法虽然名字一样，甚至连参数都差不多但是一个返回的是IEnumerable另外一个则是IQueryable

这就从本质上区别开了这两个where方法

同时注意一下IQueryable的where方法第一个参数的this关键字，这说明了什么？

说明了where并不是在IQueryable接口内部的，而是在外部类通过扩展方法的方式加上去的（这个类就是Queryable，该类中为IQueryable接口提供了n多类似where的扩展方法）

所以可以说，EF能实现延迟加载就是因为有Queryable类的存在

但是从这行代码中我们又可以看到

var user = dbEntities.T_Users.Where(u => u.Id == 2);

where方法是从dbEntities这个EF上下文对象的T_Users属性中点出来的

where方法不是在Queryable类中的吗（或者说是IQueryable接口的）

怎么就可以从EF的上下文属性中调用呢？

那么现在我们就找到EF上下文，看看T_Users属性到底是怎么回事

可以很清楚的看到T_Users是一个DbSet<T_Users>类型的泛型属性

F12转到定义看一下这个DbSet是什么东西

是不是能够在DbSet的基类（接口中）找到IQueryable！

这就解释了为什么能够在EF上下文的T_Users属性中点出where方法并使用

因为T_Users的类型继承了IQueryable接口，自然能够使用IQueryable接口中的方法啦！

上面的长篇大论简要的解释了一下EF的延迟加载机制

说了那么多，那到底为什么需要延迟加载呢？

直接取直接用不就好了？

确实从这个简单的例子来看延迟加载貌似很多余

但是通常我们操作数据库不可能只是这么简单的

就拿很常用的分页来说

一般是先对数据进行排序

然后按照要求跳过几行数据

在取几行数据

这就不是一个简单的where方法可以实现的了

至少需要先调用order进行排序，然后skip跳过几行数据，最后take取几行数据

如果where/order/skip/take等等方法每次使用的时候就马上提交sql语句到数据库

那做一个分页查询至少要发送4次请求

也就是说要和数据库交互4次

如果使用延迟加载的话

上面的where/order/skip/take方法调用的时候可以看做只是在拼凑条件

当条件满足的时候（一般就是要用数据的时候，比如说FirstOrDefault方法）

在将整个拼凑好的sql语句一起提交到数据库

这样一来和数据库的交互次数由4降到了1

这就是使用延迟加载的本质原因之一：拼凑条件一起提交，降低数据库交互次数，提高数据库的吞吐量

这也是延迟加载的优点

在本例中，T_Products中有一个外键Uid关联到T_Users

上代码：

var product = dbEntities.T_Products.Where(p => p.Uid == 2).FirstOrDefault();

Console.WriteLine(product.T_Users.UserName);

表内容如下

可以看到Uid为2有两行

取出Uid为2的T_Products集合然后获得第一行的实体

并将其关联的外键属性T_User的UserName输出

继续在每行代码设置断点并运行

程序停留在上图的位置，F5执行，命中下一个断点

可以看到，因为调用了FirstOrDefault方法

所以想数据库发送了sql语句

但是注意观察左边的sql语句

并没有将外键列一起查询出来

继续F5运行

还是观察左边的sql语句

因为执行了Console.WriteLine(product.T_Users.UserName);这行代码

需要用到外键列

此时EF才向数据库提交查询外键列的sql语句

这就是延迟加载的本质原因之二：针对外键属性，EF只有在这个外键属性用到的时候才会去查询

那么通过上面的介绍，EF延迟加载的优点已经很明显了

那么缺点是什么呢？

比如说现在的需求是

取出T_Products

var products = dbEntities.T_Products.Where(p => true);
            foreach (var p in products)
            {
                Console.WriteLine(p.T_Users.UserName);
            }

            Console.ReadKey();

表中的所有实体

遍历输出每一个实体的外键T_Users并输出其UserName

我们知道

在执行完第一行代码的时候并没有和数据库进行交互

但是此时问题来了

foreach每次一次循环都要用一次products集合中实体的外键

这就造成了每循环一次就到数据库中取一次数据

这就是EF延迟加载的缺点：每次用到外键列都会去查询一次数据库

其实这里EF内部已经做了一些列的小优化，对于相同的实体只取一次，比如说T_Products表中Uid为2的有两行，Uid为3的有两行，本来需要查询4次，经过优化之后只需要查询两次

但是当数据量十分巨大的时候，这些小优化起到的作用微乎其微

那么要怎么避免这个缺陷呢？

这时可以通过连接查询先将外键列一起查询出来在循环使用

代码如下：

var products = dbEntities.T_Products.Include("T_Users");//通过Include告诉EF连接查询哪个外键列，特别舒服的事情是，Include可以一直点下去~！
            foreach (var p in products)
            {
                Console.WriteLine(p.T_Users.UserName);
            }

            Console.ReadKey();

点击运行可以看到下图的效果

注意左边的sql语句

生成了inner join的sql语句

只进行了一次数据库交互