Entity Framework 與 LINQ to SQL 調用存儲過程差異實戰對比

Entity Framework 與 LINQ to SQL 調用存儲過程差異實戰對比

場景背景

項目同時存在 EF DbContext 與 LINQ to SQL DataContext 兩套 ORM，調用同一存儲過程 uspUpdateEmployeeLogin（6 參數），API 差異巨大，易踩坑。

Entity Framework (DbContext) 方式

using (var ctx = new AdventureWorks2014Entities()) {
    int ret = ctx.Database.ExecuteSqlCommand(
        "EXEC [HumanResources].[uspUpdateEmployeeLogin] " +
        "@BusinessEntityID, @OrganizationNode, @LoginID, @JobTitle, @HireDate, @CurrentFlag",
        new SqlParameter("@BusinessEntityID", 10),
        new SqlParameter("@OrganizationNode", DBNull.Value),
        new SqlParameter("@LoginID", @"adventure-works\michael6"),
        new SqlParameter("@JobTitle", "Research and Development Manager23"),
        new SqlParameter("@HireDate", DateTime.Now),
        new SqlParameter("@CurrentFlag", true)
    );
}

關鍵特性

• 參數化安全：SqlParameter 自動處理類型轉換、NULL 值、SQL 注入防護。
• 參數名靈活：可帶 @ 可不帶，EF 內部匹配。
• 返回值：ExecuteSqlCommand 返回受影響行數；需返回結果集用 SqlQuery。

LINQ to SQL (DataContext) 方式

using (var ctx = new AWDataClassesDataContext()) {
    // 必須手動拼接 SQL 字符串，參數內插
    string sql = string.Format(
        "EXEC [HumanResources].[uspUpdateEmployeeLogin] " +
        "@BusinessEntityID={0}, @OrganizationNode={1}, @LoginID=N'{2}', @JobTitle=N'{3}', @HireDate=N'{4}', @CurrentFlag=N'{5}'",
        10, "NULL", @"adventure-works\michael6", "Research and Development Manager12",
        DateTime.Now.ToString(), true.ToString()
    );
    int ret = ctx.ExecuteCommand(sql);
}

痛點分析

• 無參數化機制：ExecuteCommand 僅接受格式化字符串，參數為 object[] 但實測不支持 DBNull.Value、日期格式化極易出錯。
• SQL 注入風險：字符串拼接無法防範注入，單引號轉義、日期格式、NULL 處理全靠手工。
• 動態拼接地獄：可空參數需 if-else 拼接 NULL 或 N'value'，代碼極其醜陋。
• 無 IntelliSense/重構支持：存儲過程元數據無法映射到強類型方法。

深度對比表

遷移建議

1. 新項目禁用 LINQ to SQL：選 EF Core 或 Dapper。
2. 存量遷移策略：
   • 簡單 CRUD：Dapper 手寫 SQL，性能最優、無魔法。
   • 複雜域模型：EF Core Code First，遷移實體類、DbContext、遷移腳本。
   • 存儲過程：EF Core FromSqlRaw/ExecuteSqlRaw + 參數化。
3. 混用期隔離：不同模塊不同 Context，避免同一事務跨 Context（需分布式事務）。

總結

LINQ to SQL 設計器生成的 500+ 表實體類已成技術債，手動拼接 SQL 調用存儲過程是「以毒攻毒」。EF 的參數化機制、類型安全、現代化生態，是遷移的必然選擇。盡早制定遷移路線圖，停止在 LINQ to SQL 上投入新代碼。