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 的区别）