LINQ 演進歷程與對 C# 設計的影響（一）：從序列運算子到 Lambda 運算式

簡單來說，LINQ 是支援以型別安全方式查詢資料的一系列語言擴充；它將在代號為「Orcas」的下一版 Visual Studio 中釋出。待查詢資料形式可以是 XML (LINQ to XML)、資料庫 (啟用 LINQ 的 ADO.NET，包含 LINQ to SQL、LINQ to DataSet、LINQ to Entities) 與物件 (LINQ to Objects) 等。LINQ 架構如圖 1 所示。

圖 1 LINQ 架構

在即將釋出的「Orcas」版 C# 中，LINQ 查詢可能如下：

var overdrawnQuery = from account in db.Accounts
                     where account.Balance < 0
                     select new { account.Name, account.Address };

當使用 foreach 遍歷此查詢結果時，每個回傳元素將包含餘額小於 0 的帳戶名稱與地址。

從範例可見語法類似 SQL。幾年前，Anders Hejlsberg (C# 首席設計師) 與 Peter Golde 曾考慮擴充 C# 以更好整合資料查詢。Peter 時任 C# 編譯器開發主管，研究擴充 C# 編譯器可能性，特別是支援可驗證 SQL 等特定領域語言語法的增益集。Anders 則構想更深層、更特定層級的整合。他正構思一組「序列運算子」，能在實作 IEnumerable 的任何集合與實作 IQueryable 的遠端型別查詢上執行。最終，序列運算子構想獲得多數支援，Anders 於 2004 年初向比爾·蓋茨的 Thinkweek 遞交文件。回饋給予充分肯定。設計初期，簡單查詢語法如下：

sequence locals = customers.where(ZipCode == 98112);

此例中，Sequence 為 IEnumerable 別名；"where" 一詞為編譯器理解的特殊運算子。Where 運算子實作為接受 predicate 委派 (即 bool Pred(T item) 形式委派) 的一般 C# 靜態方法。構想目的是讓編輯器具備與運算子相關特殊知識，允許編譯器正確呼叫靜態方法並建立代碼，將委派與運算式連結。

假設上述為 C# 理想查詢語法。若無任何語言擴充，該查詢在 C# 2.0 中會是什麼樣子？

IEnumerable locals = EnumerableExtensions.Where(customers, delegate(Customer c)
{
    return c.ZipCode == 98112;
});

這代碼驚人地冗長，且需仔細研究才能找到相關篩選條件。這只是簡單範例；若使用多個篩選器、投影等，閱讀難度可想而知。冗長根源在於匿名方法所要求的語法。在理想查詢中，除了要計算的運算式，運算式不會提出任何要求。編譯器將嘗試推斷上下文；例如 ZipCode 實際參照 Customer 上定義的 ZipCode。如何解決？將特定運算子知識硬編碼到語言中無法令語言設計團隊滿意，因此他們開始為匿名方法尋求替代語法。他們要求該語法極其簡潔，但不需比匿名方法目前所需的編譯器知識更多。最終，他們發明了 Lambda 運算式。