EF DbContext.Configuration.ProxyCreationEnabled 什么鬼？
今天在开发项目的时候，使用 EF，突然遇到了这样一个错误：
An entity object cannot be referenceed by multiple instances of IEntityChangeTracker
这个异常我想大家应该很熟悉，大致的意思是 EF 实体操作不在同一个 DbContext，我贴下出现错误的代码：
public class AdTextUnitService : IAdTextUnitService
{
private IAdTextUnitRepository _adTextUnitRepository;
private IUnitOfWork _unitOfWork;
public AdTextUnitService(IAdTextRepository adTextRepository,
IUnitOfWork unitOfWork)
{
_adTextUnitRepository = adTextRepository;
_unitOfWork = unitOfWork;
}
public async Task<bool> Update(int id, string title)
{
var adTextUnit = await _adTextUnitRepository.Get(id);
adTextUnit.Title = title;
_unitOfWork.RegisterDirty(adTextUnit);// 这里出错
return await _unitOfWork.CommitAsync());
}
}
Update 的过程就是先使用 adTextUnitRepository 获取 adTextUnit 对象，然后进行修改，最后通过 _unitOfWork 提交更改，Repository 和 UnitOfWork 共享一个 IDbContext，具体实现请点击这里，既然共享同一个 IDbContext，那为什么还会出现上面的错误呢？并且同样的代码，我对其他实体操作却是可以，但对 AdTextUnit 操作就是不行。
对比了AdTextUnit 和其他实体的区别，发现 AdTextUnit 存在 virtual 属性，那为什么有 virtual 属性就不行呢？首先，我想到了 EF 中的 LazyLoadingEnabled（懒加载配置），然后我就在 DbContext 中进行了下面配置：
public CNBlogsAdDbContext()
{
Configuration.LazyLoadingEnabled = false;
}
但运行测试代码，发现还是出现错误，那就肯定不是 LazyLoadingEnabled 的问题，Google 搜索相关问题，发现解决方式就是“共享”同一个 IDbContext，比如下面示例代码：
//1. 操作同一 using 块中
using (var context = new CNBlogsAdDbContext())
{
var adTextUnit = context.AdTextUnit.FirstOrDefault();
adTextUnit.Title = title;
context.SaveChanges();
}
//2. DbContext 放在 HttpContext 请求中
internal static class ContextPerRequest
{
internal static CNBlogsAdDbContext Current
{
get
{
if (!HttpContext.Current.Items.Contains("context"))
{
HttpContext.Current.Items.Add("context", new CNBlogsAdDbContext());
}
return HttpContext.Current.Items["context"] as CNBlogsAdDbContext;
}
}
}
protected void Application_EndRequest(object sender, EventArgs e)
{
var entityContext = HttpContext.Current.Items["context"] as CNBlogsAdDbContext;
if (entityContext != null)
entityContext.Dispose();
}
插一段：以上内容是我下午写的，现在是晚上时间，本来很简单的问题，让我搞复杂了，汗汗汗！！！当时除了尝试 LazyLoadingEnabled 解决，还试了 IoC.RegisterPerRequestType 注入（上面的第二种解决方案），但当时写代码比较急，RegisterPerRequestType 写在了 IUnitOfWork 接口注入上（眼瞎啊），然后我以为这种方式无效，就找其他方案，虽然最后用 ProxyCreationEnabled 解决了，这个过程真是坑爹，但也加深了对 DbContext 的一些理解。
还是要记录一下，一开始的问题，我们只需要这样就可以解决（和使用 using 是一样的效果）：
IoC.RegisterPerRequestType<IDbContext, CNBlogsAdDbContext>();
RegisterPerRequestType 的具体实现，就是上面第二种解决方案，虽然解决了问题，但还是有些疑惑，下面我们做个测试：
[Fact]
public void DbContextTest()
{
var context = new CNBlogsAdDbContext();
var context2 = new CNBlogsAdDbContext();
AdTextUnit adTextUnit;
using (context)
{
adTextUnit = context.Set<AdTextUnit>().FirstOrDefault();
}
using (context2)
{
adTextUnit.DateUpdated = DateTime.Now;
context2.Entry<AdTextUnit>(adTextUnit).State = EntityState.Modified;
context2.SaveChanges();
}
}
上面的测试代码，我们是想模拟不同 DbContext 操作实体的情况，由第一个 DbContext 查询，然后第二个 DbContext 进行修改提交，执行测试代码，测试是通过并且正确，是不是有点奇怪？这种情况和我们的项目代码差不多（不使用 RegisterPerRequestType 的情况下），为什么测试代码却是可以的呢？想不通没关系，下面我们对上面测试代码进行修改，去掉 using：
[Fact]
public void DbContextTest()
{
var context = new CNBlogsAdDbContext();
var context2 = new CNBlogsAdDbContext();
AdTextUnit adTextUnit;
adTextUnit = context.Set<AdTextUnit>().FirstOrDefault();
adTextUnit.DateUpdated = DateTime.Now;
context2.Entry<AdTextUnit>(adTextUnit).State = EntityState.Modified;
context2.SaveChanges();
}
执行测试代码：
这个错误是那么的熟悉，通过测试代码，我们大致可以推断出这个错误到底是如何发生的？
下面我说一下自己的理解，EF 要修改实体对象，需要记录实体对象值的变更，怎么记录的呢？就是通过 EntityChangeTracker（注意上面错误中的 IEntityChangeTracker），比如这段代码 adTextUnit.DateUpdated = DateTime.Now;，如果这个修改操作是在一个 using 中，那 EF DbContext 会通过 EntityChangeTracker 进行记录修改值的变化，具体是怎么记录的？大家可以看下 EF 的源码，我之前有篇博文（《追根溯源：EntityFramework 实体的状态变化》也说了一点点，之前有人问我，EF 修改实体的某一个属性值，最后执行 SQL 的时候，到底是更改一个属性值，还是全部更新呢？我们看一个段简单代码：
[Fact]
public void DbContextTest()
{
using (var context = new CNBlogsAdDbContext())
{
var adTextUnit = context.Set<AdTextUnit>().FirstOrDefault();
adTextUnit.DateUpdated = DateTime.Now;
context.SaveChanges();
}
}
这段代码再简单不过，先通过 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();
}
总结几个关键点：
- AdTextUnit 的查询和修改不在一个 DbContext 中。
- 两个 DbContext 没有使用 using 块。
- AdTextUnit 存在虚拟属性。
- ProxyCreationEnabled 默认为 true。
上面这几个关键点，最后就导致了报错发生，了解了我们上面的分析，其实很简单，首先，通过 context1 获取 adTextUnit 实体对象，因为我们开启了代理，所以 adTextUnit 会进行追踪其内部的虚拟属性，并且这个追踪和 context1 密切相关，接下来通过 context2 进行修改和保存 adTextUnit 实体，需要注意的是，因为我们没有 using context1，所以这时候 adTextUnit 对应的代理追踪还是存在的，又因为我们使用 context2 强制表示 adTextUnit 进行了修改，context1 下的代理追踪，怎么能在 context2 进行标识呢？所以这时候肯定会抛出异常，这个道理用通俗的话来讲，就是老李家的儿子，跑到老张家喊爸爸，老家肯定会打断他儿子的腿。
这篇博文比较乱，而且内容和标题感觉差别也比较大，但一开始确实是由 EF DbContext.Configuration.ProxyCreationEnabled 引发的，并且一步一步测试分析，把这个过程分享出来，现在感觉还是蛮有价值的，一个点可以牵出其他很多点，对 EF 的理解和使用又进了一步，就到这！
参考资料：
- Working with Proxies
- MVC3 - an entity object cannot be referenced by multiple instances of ientitychangetracker（Proxy 讲的很详细）
- What are the downsides to turning off ProxyCreationEnabled for CTP5 of EF code first（LazyLoadingEnabled 和 ProxyCreationEnabled 的区别）
微信公众号：你好架构
出处：http://www.cnblogs.com/xishuai/
公众号会不定时的分享有关架构的方方面面，包含并不局限于：Microservices（微服务）、Service Mesh（服务网格）、DDD/TDD、Spring Cloud、Dubbo、Service Fabric、Linkerd、Envoy、Istio、Conduit、Kubernetes、Docker、MacOS/Linux、Java、.NET Core/ASP.NET Core、Redis、RabbitMQ、MongoDB、GitLab、CI/CD（持续集成/持续部署）、DevOps等等。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。
