簡單地說，LINQ 是支持以類型安全方式查詢數據的一系列語言擴展;它將在代號為“Orcas”的下一個版本 Visual Studio 中發布。待查詢數據的形式可以是 XML(LINQ 到 XML)、數據庫(啟用 LINQ 的 ADO.Net，其中包括 LINQ 到 SQL、LINQ 到 Dataset 和 LINQ 到 EntitIEs)和對象 (LINQ 到 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 == 98112)。這只是一個簡單的例子;試想一下，如果使用數個篩選器、投影等，要讀懂代碼該有多難。冗長的根源在於匿名方法所要求的語法。在理想的查詢中，除了要計算的表達式，表達式不會提出任何要求。隨後，編譯器將嘗試推斷上下文;例如，ZipCode 實際上引用了 Customer 上定義的 ZipCode。如何解決這一問題?將特定運算符的知識硬編碼到語言中並不能令語言設計團隊滿意，因此他們開始為匿名方法尋求替代語法。他們要求該語法應極其簡練，但又不必比匿名方法當前所需的編譯器要求更多的知識。最終，他們發明了 lambda 表達式。
