EF DbContext.Configuration.ProxyCreationEnabled 什么鬼？ - 田园里的蟋(2)_H5之家

这段代码再简单不过，先通过 context 获取 adTextUnit 实体对象，然后进行修改一个属性值，最后进行保存，需要注意的是，我们并没有像之前那样手动 EntityState.Modified 配置，在修改属性值的时候，EF 会通过 EntityChangeTracker 追踪这个值的修改，然后在持久化的时候，进行检测并生成最终的 SQL 代码：

exec sp_executesql N'UPDATE [dbo].[AdTextUnits] SET [DateUpdated] = @0 WHERE ([Id] = @1) ',N'@0 datetime2(7),@1 int',@0='2015-10-27 21:23:20.4506808',@1=4

从 SQL Server Profiler 捕获的 SQL，就可以看出 EF 是很智能的，如果我们把上面的测试代码，改成下面这样：

[Fact] public void DbContextTest() { using (var context = new CNBlogsAdDbContext()) { var adTextUnit = context.Set<AdTextUnit>().FirstOrDefault(); adTextUnit.DateUpdated = DateTime.Now; context.Entry<AdTextUnit>(adTextUnit).State = EntityState.Modified; context.SaveChanges(); } }

手动加了一个实体 State 修改，最后生成的 SQL 如下：

exec sp_executesql N'UPDATE [dbo].[AdTextUnits] SET [AdTextId] = @0, [AdTextModuleId] = @1, [StartDate] = @2, [EndDate] = @3, [Sort] = @4, [IsActive] = @5, [DateAdded] = @6, [DateUpdated] = @7, [OperatorName] = @8 WHERE ([Id] = @9) ',N'@0 int,@1 int,@2 datetime2(7),@3 datetime2(7),@4 int,@5 bit,@6 datetime2(7),@7 datetime2(7),@8 nvarchar(max) ,@9 int',@0=1,@1=1,@2='2015-10-19 00:00:00',@3='2016-10-19 00:00:00',@4=4,@5=1,@6='2015-10-19 00:00:00',@7='2015-10-27 21:43:16.8353133',@8=N'田园里的蟋蟀',@9=4

结果是 AdTextUnit 的全部属性进行了更新，为什么会这样呢？就是因为我们强制对 EF 说，AdTextUnit 被更改了，你记录的 EntityChangeTracker 无效了，但我们没具体指出哪个值被更改了，所以最后 EF 把所有属性值都更改了一遍，由这个示例，我们可以看出，尽量不要“多此一举”的对 Entry State 状态进行更改，什么情况下会进行更改呢？就是我们在丢失 EntityChangeTracker 的情况下，也就是说实体对象并不是由 DbContext 进行获取的，比如下面这段代码：

[Fact] public void DbContextTest() { using (var context = new CNBlogsAdDbContext()) { var adTextUnit = new AdTextUnit { Id = 1 }; adTextUnit.DateUpdated = DateTime.Now; context.Entry<AdTextUnit>(adTextUnit).State = EntityState.Modified; context.SaveChanges(); } }

注意 Modified，而不是 Added，这段代码是可以执行成功的，因为 adTextUnit 是我们手动进行创建的，如果不对 Entry State 状态进行进行设置，执行是会报错的，为什么？因为 EF 最后执行 SaveChanges 检测不到 EntityChangeTracker。

感觉越说越乱了，关于 EntityChangeTracker 就说到这，了解了这么多，感觉可以对一开始的那段测试做出一些解释，但好像还差什么？是什么呢？就是 Proxy（代理）。

Proxy（代理）：为 POCO 实体类型创建实例时，实体框架常常为充当实体代理的动态生成的派生类型创建实例。此代理重写实体的某些虚拟属性，这样可在访问属性时插入挂钩，从而自动执行操作。例如，此机制用于支持关系的延迟加载。本主题中所示方法同样适用于使用 Code First 和 EF 设计器创建的模型。

需要注意关键词：虚拟属性（virtual），这也就是为什么 AdTextUnit 有问题，而其他属性却没问题，那 Proxy 具体是什么鬼呢？其实就是这个东西：

后面一串的东西到底有什么用呢？其实它的作用就是记录虚拟属性，并修改保存和加载值，用一句话概括就是：Proxy 是实体虚拟属性的 EntityChangeTracker。

我们也可以手动进行配置，比如通过设置 ProxyCreationEnabled 取消代理：

public CNBlogsAdDbContext() { Configuration.ProxyCreationEnabled = false; }

再次执行：

会发现 AdTextUnit 的类型少了很长的“一坨东西”，另外，需要注意的是 ProxyCreationEnabled 和 LazyLoadingEnabled 有所不同，LazyLoadingEnabled 表示是否启用懒加载，也就是我们在 EF 查询实体的时候，会不会加载虚拟属性（导航属性）？如果设置为 false，就默认不启用懒加载，但我们可以使用 Inculde 进行手动加载，但 ProxyCreationEnabled 表示的是追踪，它和 EntityChangeTracker 很类似，只不过局限于实体的虚拟属性。

最后，我们再来说下这段测试代码，为什么会报错？

[Fact] public void DbContextTest() { var context1 = new CNBlogsAdDbContext(); var context2 = new CNBlogsAdDbContext(); AdTextUnit adTextUnit; adTextUnit = context1.Set<AdTextUnit>().FirstOrDefault(); adTextUnit.DateUpdated = DateTime.Now; context2.Entry<AdTextUnit>(adTextUnit).State = EntityState.Modified; context2.SaveChanges(); }

总结几个关键点：

上面这几个关键点，最后就导致了报错发生，了解了我们上面的分析，其实很简单，首先，通过 context1 获取 adTextUnit 实体对象，因为我们开启了代理，所以 adTextUnit 会进行追踪其内部的虚拟属性，并且这个追踪和 context1 密切相关，接下来通过 context2 进行修改和保存 adTextUnit 实体，需要注意的是，因为我们没有 using context1，所以这时候 adTextUnit 对应的代理追踪还是存在的，又因为我们使用 context2 强制表示 adTextUnit 进行了修改，context1 下的代理追踪，怎么能在 context2 进行标识呢？所以这时候肯定会抛出异常，这个道理用通俗的话来讲，就是老李家的儿子，跑到老张家喊爸爸，老家肯定会打断他儿子的腿。

这篇博文比较乱，而且内容和标题感觉差别也比较大，但一开始确实是由 EF DbContext.Configuration.ProxyCreationEnabled 引发的，并且一步一步测试分析，把这个过程分享出来，现在感觉还是蛮有价值的，一个点可以牵出其他很多点，对 EF 的理解和使用又进了一步，就到这！

参考资料：

posted @