在中，我提出了在使用LINQ to SQL进行更新操作时可能会遇到的几种问题。其实这并不是我一个人遇到的问题，当我在互联网上寻找答案时，我发现很多人都对这个话题发表过类似文章。但另我无法满足的是，他们尽管提出了问题，却没有进行详细的剖析，只给出了解决方案（如添加RowVersion列、去除关联等），但却没有说明为什么必须这么做。这也是我写上篇的初衷，希望通过对LINQ to SQL源代码的分析，来一步一步找出解决问题的办法。本文将对这些方法一一进行讨论。

方案一：重新赋值

在、和等人的开源框架中，有些地方采取了重新赋值的方法。在Update方法内部，根据主键获取数据库中的实体，然后与参数中的实体对其属性一一赋值。

public void UpdateProfile(Profile p){    using (RepositoryContext db = new RepositoryContext())    {        var profile = db.GetTable
    
     ().First
     
      (u => u.ID == p.ID);        profile.Birthday = p.Birthday;        profile.Gender = p.Gender;        profile.Hometown = p.Hometown;        profile.MSN = p.MSN;        profile.NickName = p.NickName;        profile.PhoneNumber = p.PhoneNumber;        profile.QQ = p.QQ;        profile.State = p.State;        profile.TrueName = p.TrueName;        profile.StateRefreshTime = p.StateRefreshTime;        profile.Avatar = p.Avatar;        profile.Website = p.Website;        db.SubmitChanges();    }}
     
    

也同样给出了该方案的，实现属性值的自动拷贝。

但我个人认为这是一种避实就虚的方案，没有使用LINQ to SQL提供的用于更新操作的API，而采取了一种迂回的策略。这其实是一种妥协，难道因为Attach方法“不好用”，我们就不用了吗？呵呵。

方案二：禁用对象跟踪

对此，提出可以通过，来达到正确更新的目的。

public Product GetProduct(int id){    NorthwindDataContext db = new NorthwindDataContext();    db.ObjectTrackingEnabled = false;    return db.Products.SingleOrDefault(p => p.ProductID == id);}

其他的代码没有任何变化。

为什么禁用对象跟踪之后，就能正常更新了呢？我们还是从源代码中来寻找答案吧。

public bool ObjectTrackingEnabled{    get    {        this.CheckDispose();        return this.objectTrackingEnabled;    }    set    {        this.CheckDispose();        if (this.Services.HasCachedObjects)        {            throw System.Data.Linq.Error.OptionsCannotBeModifiedAfterQuery();        }        this.objectTrackingEnabled = value;        if (!this.objectTrackingEnabled)        {            this.deferredLoadingEnabled = false;        }        this.services.ResetServices();    }}

原来设置ObjectTrackingEnabled为false时，会同时将DeferredLoadingEnabled设置为false。这样，在执行查询时，将不会为实体加载任何需延迟查询的数据，因此Attach时也不会抛出异常（见）。

在MSDN中我们还得到下面这条有用的信息：将ObjectTrackingEnable属性设置为false，可以提高检索时的性能，因为这样可以减少要跟踪的项目。这真是一个很有诱惑的特性。

但禁用对象跟踪时，要特别注意两点：（1）必须在执行查询前禁用。（2）禁用之后不能再调用Attach和SubmitChanges方法。否则都将引发异常。

方案三：移除关联

在中已经介绍一个蹩脚的方法，即在GetProduct方法中手动设置与Product关联的Category为null。我们可以把这部分代码提取出来，放入一个Detach方法中。因为这个Detach是实体的方法，可以使用分部类：

public partial class Product{    public void Detach()    {        this._Category = default(EntityRef
    
     );    }}public partial class Category{    public void Detach()    {        foreach (var product in this.Products)        {            product.Detach();        }    }}
    

但是这种对每个实体都定义Detach的方法过于繁琐。随着实体的增多，关系越来越复杂，很容易出现漏掉的属性。张逸提出了，利用反射对该逻辑进行抽象：

private void Detach(TEntity entity){    foreach (FieldInfo fi in entity.GetType().GetFields(BindingFlags.NonPublic | BindingFlags. Instance))    {        if (fi.FieldType.ToString().Contains("EntityRef"))        {            var value = fi.GetValue(entity);            if (value != null)            {                fi.SetValue(entity, null);            }        }        if (fi.FieldType.ToString().Contains("EntitySet"))        {            var value = fi.GetValue(entity);            if (value != null)            {                MethodInfo mi = value.GetType().GetMethod("Clear");                if (mi != null)                {                    mi.Invoke(value, null);                }                fi.SetValue(entity, value);            }        }    }}

在Detach时应该，但总体的思路是一样的。

方案四：使用委托

这是在我给出的方法，我个人认为非常值得借鉴。

public void UpdateProductWithDelegate(Expression
    
     
      > predicate, Action 
      
        action){    NorthwindDataContext db = new NorthwindDataContext();    var product = db.Products.SingleOrDefault(predicate);    action(product);    db.SubmitChanges();}// Client codeProductRepository repository = new ProductRepository();repository.UpdateProductWithDelegate(p => p.ProductID == 1, p =>    {        p.ProductName = "Changed";    });
      
     
    

使用Lambda表达式将GetProduct的逻辑植入UpdateProduct中，并且使用委托将更新逻辑也延缓执行，这样巧妙地将查找和更新放进了一个DataContext里，从而绕开了Attach。但是这种方法API有些过于复杂，对客户端编程人员的水平要求过高。而且在Update里还要执行一遍Get的逻辑，尽管性能上的损失微乎其微，但看上去总多多少少给人一种不够DRY的感觉。

方案五：使用UPDATE语句

在的源代码中，我发现了RepositoryBase.UpdateEntity方法。在方法内部进行SQL语句的拼接，并且将只更新发生更改的列。由于此处已经不再使用ITable，并且需要完整的框架支持，因此不再进行过多的评述。详情请参考Ezsocio的源代码。

总结

本文列举了近几天我在互联网上找到的几种解决方案，它们各有利弊，孰优孰劣，见仁见智。在下篇中，我将对这几种方法进行性能上的比较，从而找出最优方案。

相关文章