如何查找 EF CodeFirst CTP5 中正在跟踪更改的所有对象的来源？

Question

我遇到“实体对象无法被 IEntityChangeTracker 的多个实例引用”问题。经过一番检查后，我似乎有一个正在跟踪更改的对象。问题是我不知道问题对象的来源...它显然已放入上下文中，但我不确定哪个调用尚未正确分离。

因此，经过几个小时的尝试解决这个问题后，我正在寻找如何遍历树来查找与我发生冲突的源对象，因为这也许会帮助我了解源对象的添加位置。

该错误是在第 226 行抛出的，因此看起来我要么存在一个“隐形”客户，要么可能是客户的某个属性导致了此问题，因为客户还有几个其他属性，这些属性是它们自己的复杂对象类型。 ..

Line 224:                    if (null != this.Customer)
Line 225:                    {
Line 226:                        context.Entry(this.Customer).State = EntityState.Unchanged;
Line 227:                    } 

该错误并没有说明哪个对象导致了错误，它只是指向第226行。在假设它是导致此错误的幻影 Customer 对象时，我已经尝试过：

        var test = ((IObjectContextAdapter)dataContext).ObjectContext.ObjectStateManager.GetObjectStateEntries(EntityState.Added | EntityState.Deleted | EntityState.Modified | EntityState.Unchanged);

        foreach(var e in test)
        {
            if(e.GetType() == typeof(Customer))
            {
                dataContext.Detach(e);
            }
        }

这个想法是循环遍历保存所有对象引用的东西，希望找到顽皮的客户并给它启动。但是，唉，这并没有奏效。在此循环中未找到任何客户。哦，仅供参考 - 这是在前面的代码之前运行的几行，所以我不会在那里偷偷创建任何额外的对象。

所以我需要一种方法来确定哪个对象实际上导致了错误。

@Ladislav - 仅供参考 - 我有一个包含所有业务对象（BO）的公共库。这个公共库被其他项目使用——Windows服务、Web服务等。我试图让每个BO负责填充和保存自己，这样我就没有一个hugo数据访问类。每个 BO 负责它自己的 Save() 方法。这是 current saveUpdate 方法的示例：

    public void SaveOrUpdate(DataContext context)
    {
        if (context.Entry(this).State == EntityState.Detached)
        {
            context.Customers.Add(this);
            context.SaveChanges();
        }
        else //update
        {
            context.Entry(this).State = System.Data.EntityState.Modified;
            context.SaveChanges();
        }
    }

关于您对范围的建议，我尝试了各种策略 - 乍一看每个人都说原子地执行 - 所以我让每个方法获取一个新的实例DataContext 来完成它的工作。只要对象不是很复杂，并且不相互依赖，即只包含像 int 和 string 这样的基本类型属性，这种方法就可以很好地工作。

但是，当我开始遇到这些并发错误时，我深入研究并发现 DataContext 以某种方式保留了对对象的引用即使它被处置了这是一个有点疯狂糟糕的工程， 恕我直言。也就是说，如果我将一个 Customer BO 添加到 DataContext，然后允许 DataContext 超出范围并被处理，然后启动一个新的 DataContext 来执行某些操作，则原始的 Customer BO 指针仍然存在！

所以我在 StackOverflow 上读了很多（我可能会补充一下你的很多答案）， Rick Strahl 关于 DataContext 生命周期管理的论文 和 8 实体Julia Lerman 的框架陷阱

所以 Julia 说放入一个 Dispose 方法，我也这么做了，但这没有帮助，DataContext 仍然神奇地保留着引用。

因此，Rick 说尝试使用“全局”DataContext，这样您就只需担心一个 DataContext，并且它应该知道正在发生的一切，因此它不会踩到自己的脚趾。但这似乎也不起作用。公平地说，Rick 谈论的是 Linq to SQL 和 Web 应用程序，但我有点希望它也适用于我。

然后各种答案说你不想要一个全局DataContext，因为它会变得非常大，非常快，因为它保存了所有对象的所有信息，所以只需使用DataContext 工作单元。

好吧，我已经将工作单元分解为对您希望一起完成的一组对象所做的所有更改、添加和更新。对于我的示例，以下是一些 BO 和属性：

MessageGroup
- 属性：列表
- 属性：客户

客户
- 属性：列表
- 属性：列表

消息
- 财产：客户
- 属性：消息组
- 属性：用户

用户
- 财产：客户
- 属性：列表

在系统中，当 MessageGroup 到达（以 Xml 形式）时，将对其进行检查和解析。 MessageGroup 构造函数使用依赖注入并将 DataContext 作为其参数之一 - 因此正在创建的所有“子”BO 都使用 DataContext 的这一实例。从数据库中获取客户（或创建一个新客户）并将其分配给 MessageGroup...让我们假设它是一个现有客户 - 因此不需要对其进行更新，它是新鲜的的数据上下文。

然后循环 MessageGroup.Messages 列表，并且要创建的第一个子 BO 是一个新的 User 对象。我将相同的 Customer 对象（来自 MessageGroup）分配给 User。但是，当调用 context.Users.Add(this) 时，我收到错误。如果我不将客户分配给用户，则不会收到错误消息。

所以现在我有一个来自数据库的新客户（或子属性，我不确定），我不需要跟踪它，这会引起我的焦虑。我想我可以通过使用类似以下内容从上下文中删除它：

var cust = Customer.GetCustomerFromExternalId(crm.CustomerId);
dataContext.Detach(cust);
dataContext.SaveChanges();

但我仍然收到错误，即使我已经明确删除了它。当然，如果它是 Customer 的子属性之一，也许它还没有被删除？

目前我想知道存储库模式是否适合我的目的。我还想知道 EF CodeFirst 是否存在根本缺陷或过于复杂？也许我应该使用 SubSonic 或 NHibernate 来代替？

Answer 1

据我所知，可能没有明确的方法从 POCO 实体获取相关上下文 - 动态代理的所有相关属性都是非公开的。要检查 DbContext 中的实体，请使用：

context.ChangeTracker.Entries<Customer>().Where(e => e.State == ...)

避免问题的最佳方法是每个“工作单元”使用单个上下文。如果您有来自多个上下文的实体，您显然不会遵循这种方法。此外，您似乎正在使用多个并发活动上下文。