LINQ to SQL 優缺點深度分析：從動態查詢、效能到批次更新實務

優點

• 編譯期型別檢查：查詢語法錯誤在建置時即可發現，非執行期。
• 物件導向查詢：直接操作實體類別，符合 OO 思維，減少 SQL 字串拼接。
• 自動生成對應代碼：VS 提供 O/R 設計師與 SqlMetal，一鍵生成實體與 DataContext。
• 延遲載入：導覽屬性存取時才發送 SQL，減少不必要查詢。
• 身分追蹤與快取：同一 DataContext 內相同實體只查詢一次資料庫。
• 參數化查詢：自動參數化，防止 SQL 注入，利於計畫重用。

缺點與挑戰

1. 動態查詢困難

需依使用者選擇動態排序/篩選欄位時，純 LINQ 難以表達：

// 錯誤：OrderBy 不接受字串
var q = db.Customers.OrderBy("CompanyName"); 

// 解法 1：Switch 分支（維護性差）
switch (sortField) {
    case "ID": q = q.OrderBy(c => c.ID); break;
    case "Name": q = q.OrderBy(c => c.Name); break;
}

// 解法 2：Dynamic LINQ Library (System.Linq.Dynamic)
using System.Linq.Dynamic;
var q = db.Customers.OrderBy("CompanyName").Where("City == @0 AND Orders.Count >= @1", "London", 10);

Dynamic LINQ 內部以運算式樹動態建構，效能略低但彈性極高。

2. 批次更新/刪除效能問題

SubmitChanges() 逐筆發送 UPDATE/DELETE，大量資料極慢。

// 解法：ExecuteCommand 直接下 SQL 批次更新
db.ExecuteCommand("UPDATE Products SET UnitPrice = UnitPrice + 1.00 WHERE Discontinued = 0");

或使用 ExecuteQuery<T>() 回傳實體集合。

3. 複雜查詢產生低效 SQL

• 多層導覽屬性易產生 N+1 查詢 → 使用 DataLoadOptions.LoadWith 預載。
• 複雜 GroupBy/Join 可能產生難以調優的 SQL → 改用預存程序或 View 映射實體。

效能優化實務

何時選擇 LINQ to SQL？

• 團隊熟悉 C#、專案中小型、資料模型穩定、需快速開發。
• 不需跨資料庫平台（僅 SQL Server）。
• 可接受偶爾手寫 SQL 處理複雜/批次操作。

替代方案

• Entity Framework Core：跨平台、功能更豐富、積極維護中。
• Dapper：微型 ORM，手寫 SQL、效能極佳、適合高併發核心路徑。
• 預存程序 + ADO.NET：極致效能與資料庫端邏輯封裝。

結語

LINQ to SQL 降低了資料存取門檻，但非銀彈。理解其運作機制（運算式樹、延遲載入、變更追蹤），在動態查詢用 Dynamic LINQ，批次操作用 ExecuteCommand，複雜報表用 View/SP，才能發揮最大效益。技術選型應依專案規模、團隊技能、效能需求綜合判斷，「揚長避短，才是正道。」