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 的理解和使用又进了一步，就到这！

EF DbContext.Configuration.ProxyCreationEnabled 什么鬼？

热门文章

最新文章

相关电子书