LINQ體系結(jié)構(gòu)概述
Linq有很多值得學(xué)習(xí)的地方，這里我們主要介紹LINQ體系結(jié)構(gòu)，包括介紹Where 運(yùn)算符的實(shí)現(xiàn)等方面。
簡單地說，LINQ 是支持以類型安全方式查詢數(shù)據(jù)的一系列語言擴(kuò)展；它將在代號為“Orcas”的下一個版本 Visual Studio 中發(fā)布。待查詢數(shù)據(jù)的形式可以是 XML（LINQ 到 XML）、數(shù)據(jù)庫（啟用 LINQ 的 ADO.NET，其中包括 LINQ 到 SQL、LINQ 到 Dataset 和 LINQ 到 Entities）和對象 (LINQ 到 Objects) 等。LINQ體系結(jié)構(gòu)如下圖所示。
LINQ體系結(jié)構(gòu)
讓我們看一些代碼。在即將發(fā)布的“Orcas”版 C# 中，LINQ 查詢可能如下所示：
- var overdrawnQuery = from account in db.Accounts where account.
Balance < 0select new { account.Name, account.Address };
當(dāng)使用 foreach 遍歷此查詢的結(jié)果時，返回的每個元素都將包含一個余額小于 0 的帳戶的名稱和地址。
從以上示例中立即可以看出該語法類似于 SQL。幾年前，Anders Hejlsberg（C# 的***設(shè)計師）和 Peter Golde 曾考慮擴(kuò)展 C# 以更好地集成數(shù)據(jù)查詢。Peter 時任 C# 編譯器開發(fā)主管，當(dāng)時正在研究擴(kuò)展 C# 編譯器的可能性，特別是支持可驗(yàn)證 SQL 之類特定于域的語言語法的加載項(xiàng)。另一方面，Anders 則在設(shè)想更深入、更特定級別的集成。他當(dāng)時正在構(gòu)思一組“序列運(yùn)算符”，能在實(shí)現(xiàn) IEnumerable 的任何集合以及實(shí)現(xiàn) IQueryable 的遠(yuǎn)程類型查詢上運(yùn)行。最終，序列運(yùn)算符的構(gòu)思獲得了大多數(shù)支持，并且 Anders 于 2004 年初向比爾·蓋茨的 Thinkweek 遞交了一份關(guān)于本構(gòu)思的文件。反饋對此給予了充分肯定。在設(shè)計初期，簡單查詢的語法如下所示：
- sequence<Customer> locals = customers.where(ZipCode == 98112);
在此例中，Sequence 是 IEnumerable<T> 的別名；“where”一詞是編譯器能理解的一種特殊運(yùn)算符。Where 運(yùn)算符的實(shí)現(xiàn)是一種接受 predicate 委托（即 bool Pred<T>(T item) 形式的委托）的普通 C# 靜態(tài)方法。本構(gòu)思的目的是讓編輯器具備與運(yùn)算符有關(guān)的特殊知識。這樣將允許編譯器正確調(diào)用靜態(tài)方法并創(chuàng)建代碼，將委托與表達(dá)式聯(lián)系起來。假設(shè)上述示例是 C# 的理想查詢語法。在沒有任何語言擴(kuò)展的情況下，該查詢在 C# 2.0 中又會是什么樣子？
- IEnumerable<Customer> locals = EnumerableExtensions.
- Where(customers,delegate(Customer c)
- {
- return c.ZipCode == 98112;
- };
這個代碼驚人地冗長，而且更糟糕的是，需要非常仔細(xì)地研究才能找到相關(guān)的篩選器 (ZipCode == 98112)。這只是一個簡單的例子；試想一下，如果使用數(shù)個篩選器、投影等，要讀懂代碼該有多難。冗長的根源在于匿名方法所要求的語法。在理想的查詢中，除了要計算的表達(dá)式，表達(dá)式不會提出任何要求。隨后，編譯器將嘗試推斷上下文；例如，ZipCode 實(shí)際上引用了 Customer 上定義的 ZipCode。如何解決這一問題？將特定運(yùn)算符的知識硬編碼到語言中并不能令語言設(shè)計團(tuán)隊(duì)滿意，因此他們開始為匿名方法尋求替代語法。他們要求該語法應(yīng)極其簡練，但又不必比匿名方法當(dāng)前所需的編譯器要求更多的知識。以上介紹LINQ體系結(jié)構(gòu)。
【編輯推薦】
