在前一篇文章中，我提出了在使用LINQ to SQL進行更新操作時可能會遇到的幾種問題。其實這并不是我一個人遇到的問題，當我在互聯網上尋找答案時，我發現很多人都對這個話題發表過類似文章。但另我無法滿足的是，他們盡管提出了問題，卻沒有進行詳細的剖析，只給出了解決方案（如添加RowVersion列、去除關聯等），但卻沒有說明為什么必須這么做。這也是我寫上篇的初衷，希望通過對LINQ to SQL源代碼的分析，來一步一步找出解決問題的辦法。本文將對這些方法一一進行討論。

方案一：重新賦值

在TerryLee、Anytao和Ding Xue等人的開源框架Ezsocio中，有些地方采取了重新賦值的方法。在Update方法內部，根據主鍵獲取數據庫中的實體，然后與參數中的實體對其屬性一一賦值。

public void UpdateProfile(Profile p){    using (RepositoryContext db = new RepositoryContext())    {        var profile = db.GetTable<Profile>().First<Profile>(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方法“不好用”，我們就不用了嗎？呵呵。

方案二：禁用對象跟蹤

對此，lea提出可以通過將DataContext的ObjectTrackingEnabled屬性設置為false，來達到正確更新的目的。

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<Category>);    }}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時應該把PropertyChanging和PropertyChanged事件設置為null，但總體的思路是一樣的。

方案四：使用委托

這是ZC29同學在我上一篇文章的評論里給出的方法，我個人認為非常值得借鑒。

public void UpdateProductWithDelegate(Expression<Func<Product, bool>> predicate, Action
<Product> 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的感覺。