LINQ那些事(9)-解析Table<T>.Attach引发的异常和解决方法

起因主要是因为看到博客园又有朋友开始讨论LINQ2SQL的问题，这次说的是Attach。通过解读Attach，可以发现LINQ2SQL内部是如何维护和跟踪对象实例、如何实现延迟加载，并且还可以引发关于延迟加载和N-Tier Application中LINQ2SQL的应用技巧的讨论。本文所讨论内容适用于.Net Framework 3.5版本的LINQ2SQL，所使用数据库是Northwnd。

对于对象添加和删除操作，LINQ2SQL在Table<T>类定义中直接提供了InsertOnSubmit()/DeleteOnSubmit()。而对于对象的更新，由于LINQ2SQL中采取了对象跟踪的机制（可参考LINQ2SQL对象生命周期管理），所以我们在修改了对象属性后无需显式通知DataContext，当调用DataContext.SubmitChanges()时会自动的把我们所做的修改提交到数据库保存。这种基于上下文的操作是非常方便的，否则在代码中会出现大量的Update调用，但是也存在限制——只有在同一个DataContext对象的作用域内，对象所做的修改才会在SubmitChanges()时得到保存。如：

            using (var context = new Northwnd())
            {
                var customer = context.Customers.First();
                customer.City = "Beijing";
                context.SubmitChanges();
            }

而在Web和N-Tier Application开发时，数据查询和更新同在一个DataContext中往往得不到满足，所以LINQ2SQL在Table<T>类定义了Attach方法，用于把已与查询DataContext上下文断开的对象关联到Table所属的DataContext对象，这样就可以通过新的DataContext执行对象的更新操作。如：

            Customer customer = null;
	
            using (var context1 = new Northwnd())
            {
                customer = context1.Customers.First();
            }

            customer.City = "Beijing";

            using (var context = new Northwnd())
            {
                context.Customers.Attach(customer);
                context.SubmitChanges();
            }

但是问题来了，这段代码执行错误，抛出以下异常：

System.NotSupportedException: An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext. This is not supported.

这个问题已经不是一个新鲜的问题了，google一下有很多的解决方法，但这看起来很正常的代码为什么会抛出异常呢？其实还是和DataContext的作用域有关的，本文尝试剖析这个问题，然后还会讨论在N-Tier Application中使用LINQ2SQL的一些须知技巧。

都是Association惹的祸？

出错的地方在System.Data.Linq.Table<T>.Attach(TEntity entity, bool asModified)，下列条件只要满足其中一个，就会造成Attach调用失败：

1、DataContext为只读，相当于把DataContext.ObjectTrackingEnabled=false。只读的DataContext只能进行数据的查询，其他的操作都会抛出异常。

2、当调用Attach时，DataContext正在执行SubmitChanges()操作。

3、DataContext对象已经被显式调用Dispose()销毁。

4、asModified为true，但TEntity类的属性映射信息（MetaType）中包含UpdateCheck=WhenChanged或UpdateCheck=Always设置。这是因为Attach的对象在当前DataContext中并没有原始值的记录，DataContext无法根据UpdateCheck的设置生成where字句以避免并发冲突。需要说明的是几乎不会用到asModified=true的调用，尤其是在对查询显示-用户修改-提交保存这样的Web应用场景，本文稍后会讨论这样的场景如何操作。如果坚持要用asModified=true的调用，那么可以在TEntity类增加RowVersion属性的定义，LINQ2SQL引入RowVersion就是为了提供除UpateCheck以外的另一个冲突检测的方法，由于RowVersion应该在每一次更新操作后都应该修改，所以一般对应Timestamp类型。

5、尝试Attach一个已属于当前DataContext上下文的对象。

6、尝试Attach的对象包含未载入的Assocation属性，或是未载入的嵌套Association属性。

其中原因（6）属于本文的讨论内容，我们来看看Attach函数中的调用

...
if (trackedObject == null)
    {
        trackedObject = this.context.Services.ChangeTracker.Track(entity, true);
    }
...

Attach函数中调用StandardChangeTracker.Track(TEntity entity, bool recursive)方法，请注意第二个参数表示递归，Attach调用Track(entity, true)会导致entity的所有嵌套Association属性都会被检查。代码就是在StandardChangeTracker.Track中抛出了异常：

...
if (trackedObject.HasDeferredLoaders)
{
	throw Error.CannotAttachAddNonNewEntities();
}
....

再看看trackedObject.HasDeferredLoaders做了什么：

internal override bool HasDeferredLoaders
{
    get
    {
        foreach (MetaAssociation association in this.Type.Associations)
        {
            if (this.HasDeferredLoader(association.ThisMember))
            {
                return true;
            }
        }
        foreach (MetaDataMember member in from p in this.Type.PersistentDataMembers
            where p.IsDeferred && !p.IsAssociation
            select p)
        {
            if (this.HasDeferredLoader(member))
            {
                return true;
            }
        }
        return false;
    }
}

很快就要找到关键点了，在看看this.HasDeferredLoader：

private bool HasDeferredLoader(MetaDataMember deferredMember)
{
    if (!deferredMember.IsDeferred)
    {
        return false;
    }
    MetaAccessor storageAccessor = deferredMember.StorageAccessor;
    if (storageAccessor.HasAssignedValue(this.current) || storageAccessor.HasLoadedValue(this.current))
    {
        return false;
    }
    IEnumerable boxedValue = (IEnumerable) deferredMember.DeferredSourceAccessor.GetBoxedValue(this.current);
    return (boxedValue != null);
}

答案揭晓：storageAccessor.HasAssignedValue检测了Association属性是否被赋值（针对EntityRef），storageAccessor.HasLoadedValue检测了Association属性是否已被加载（针对EntitySet），如果没有任何的赋值或加载，并且由GetBoxedValue获取的延迟源对象（DeferredSource）不为空，则抛出异常。

要解释Attach为什么在这种情况下会抛出异常？首先要弄明白延迟源对象，这是LINQ2SQL实现延迟加载的关键。在延迟加载的模式(DataContext.DeferredLoading=true)下，EntitySet和EntityRef属性只有当被访问时，才会产生数据库的查询。以EntitySet为例，当调用GetEnumerator()时：

public IEnumerator<TEntity> GetEnumerator()
{
    this.Load();
    return new Enumerator<TEntity>((EntitySet<TEntity>) this);
}

this.Load中调用了延迟源进行数据的加载：

public void Load()
{
    if (this.HasSource)
    {
        ItemList<TEntity> entities = this.entities;
        this.entities = new ItemList<TEntity>();
        foreach (TEntity local in this.source)
        {
            this.entities.Add(local);
        }
...
    }
}

再进一步就要追溯到System.Data.Linq.CommonDataServices.GetDeferredSourceFactory(MetaDataMember)和System.Data.Linq.Mapping.EntitySetValueAccessor。当DataContext对象初始化模型信息时，会调用GetDeferredSourceFactory为指定属性生成相应的DeferredSourceFactory对象，该工厂对象通过CreateDeferredSource()生成延迟源对象。在执行查询操作时，DataContext将会调用每个对象的EntitySet属性的SetSource方法，为每一个EntitySet绑定延迟源，由延迟源来调用DataContext实现延迟加载，这样就实现了EntitySet和DataContext的解耦，让POCO类也变智能了。对于EntitySet，当执行延迟加载后，延迟源将被清空，并且相应的已加载标志也将设为true。

接下来我们验证一下，为了方便示例我只保留Customer类的Orders作为唯一的Association属性：（文章最后会给出代码下载，有兴趣可以照着验证）

            Customer customer = null;
            
            using (var context = CreateNorthwnd())
            {
                customer = context.Customers.First();
                // forces to load order association
                customer.Orders.Count.Dump();
            }

            customer.City = "Beijing";

            using (var context = CreateNorthwnd())
            {
                context.Customers.Attach(customer);
                context.SubmitChanges();
            }

别急，还是错的！虽然customer.Orders.Count的调用让customer.Orders被加载，但Order对象还包含几个未被加载的Association属性，你把Order对象的Association属性定义去掉就对了！

剖析到这里你明白为什么当存在Association或嵌套Association未被赋值或加载，且延迟源不为空时会抛出异常了么？这是因为和需要Attach的对象一样，延迟源关联的DataContext对象已经被销毁了，延迟源无法在加载数据，所以DataContext拒绝关联这样的对象。

说了那么多，是为了让大家能够明白为什么会产生异常，解决的方法很简单，不需要修改实体的定义，同时也是个人认为LINQ2SQL最佳实践之一：

            Customer customer = null;

            using (var context = CreateNorthwnd())
            {
                var option = new DataLoadOptions();
                // disabled the deferred loading
                context.DeferredLoadingEnabled = false;
                // specify the association in needed
                option.LoadWith<Customer>(c => c.Orders);
                context.LoadOptions = option;

                customer = context.Customers.First();
            }

            customer.City = "Beijing";

            using (var context = CreateNorthwnd())
            {
                context.Customers.Attach(customer);
                context.Refresh(RefreshMode.KeepCurrentValues, customer);
                context.SubmitChanges();
            }

首先我们关闭了DataContext的延迟加载，并且通过DataLoadOption显式指定了需要加载的关联数据，这样的做法不但解决Attach的问题，而且还避免了在N-Tier Application中由于延迟加载所可能导致的异常。

LINQ2SQL最佳实践

文章最后罗列一些我自己总结的应用LINQ2SQL的心得。

1、建议通过using来使用DataContext对象，这样当操作完毕立即销毁DataContext对象。默认状态下（ObjectTrackingEnabled=true），DataContext将在内存中保存查询对象的副本，如果长时间保持DataContext对象，会造成内存不必要的占用。

2、对于仅查询的操作，设ObjectTrackingEnabled=false，关闭对象跟踪有助于提高DataContext的查询性能，这也是所谓的只读DataContext。再根据所需数据，设置DataLoadOption.AssociateWith()、DataLoadOption.LoadWith()，可实现高效的查询。

3、当用LINQ2SQL编写N-Tier Application时，建议关闭延迟加载，因为这带来的麻烦远远大于好处。注意当ObjectTrackingEnabled=false时，延迟加载是不可用的，相当于DataContext.DeferredLoading=false。

4、Attach(entity, false) + DataContext.Refresh(RefreshMode.KeepCurrentValues, entity) + SubmitChanges()，实现断开对象的更新，这就避免了DuplicateKey的问题，如上面给出的代码所示。

下载

Demo Code: https://files.cnblogs.com/chwkai/LinqAttach.rar

链接

LINQ那些事（总）

LINQ那些事(6) - 对象生命周期管理

LINQ那些事(9)-解析Table<T>.Attach引发的异常和解决方法

都是Association惹的祸？

LINQ2SQL最佳实践

下载

链接

相关讨论

公告