LINQ to SQL 部分更新陷阱：Attach/Refresh 導致未指定欄位變 NULL 的解決方案

問題情境

實體類別欄位較多，但每次更新僅需修改部分欄位。使用 Attach + Refresh(KeepCurrentValues) 時，未賦值的欄位會被更新為 NULL，產生如下 SQL：

UPDATE [dbo].[log] SET [logMessage] = @p1, [x] = @p2 WHERE [logId] = @p0
-- @p2 變成 NULL，導致資料遺失

嘗試 1：先查詢再修改 → 發生「實體已載入其他 DataContext」例外

var n1 = (from x in dc.log select x).SingleOrDefault(c => c.logId == 1);
n1.logMessage = "xxxy";
updateRe(n1); // 拋出：已嘗試 Attach 或 Add 實體，該實體不是新實體...

無法輕易將實體從原 DataContext 脫離。

方案 A：實作 Clone 方法 (可行但不優雅)

public partial class log
{
    public log Clone()
    {
        return new log
        {
            logId = this.logId,
            logMessage = this.logMessage,
            x = this.x
        };
    }
}

// 使用
var n1 = ((from x in dc.log select x).SingleOrDefault(c => c.logId == 1)).Clone();
n1.logMessage = "xxxy";
updateRe(n1); // 產生正確 SQL：僅 UPDATE logMessage

缺點：每個實體類別都要手寫 Clone，維護成本高；新增欄位易忘記同步。

方案 B：委派模式更新 (推薦，來自網友 Gray Zhang)

核心概念：**在同一個 DataContext 內查詢、修改、提交**，避免跨 Context Attach 問題。

static void Update(int id, Action<log> updater)
{
    using (var ctx = new DataClasses1DataContext())
    {
        ctx.Log = Console.Out; // 觀察 SQL
        log entity = ctx.log.First(c => c.logId == id);
        updater(entity);       // 執行呼叫端傳入的修改邏輯
        ctx.SubmitChanges();
    }
}

// 呼叫範例
public static void SetLogMessage(log l) { l.logMessage = "xxtx"; }

static void Main()
{
    Update(1, SetLogMessage); // 或 Update(1, l => l.logMessage = "new value");
}

優缺點比較

最佳實務建議

1. 短生命週期 DataContext：每個業務操作/HTTP Request 建立獨立 Context，用完即棄。
2. 避免跨 Context Attach：若需離線實體，考慮 DTO 傳輸，重新查詢後套用變更。
3. 使用 partial class 擴充：在 partial class 中加入 `ApplyChanges(DTO dto)` 方法，集中映射邏輯。
4. 升級至 Entity Framework Core：context.Attach(entity).Property(e => e.Field).IsModified = true 精確控制欄位更新。

結語

LINQ to SQL 的 Attach/Refresh 設計初衷是處理離線實體，但在「部分更新」場景下極易誤傷未載入欄位。**委派模式**以最少程式碼完美解決問題，並自然契合「單一工作單元」原則。若專案允許，遷移至 EF Core 將獲得更強大的異動追蹤與更新控制能力。