LINQ to Entities 概觀
目前撰寫大部分商務應用程式的目的，是要存取關聯式資料庫中的資料。同時，這些應用程式將必須與關聯式格式表示的資料互動。關聯式模式是為了有效儲存和擷取而最佳化，而不是為了物件導向程式設計內所用的概念模型。多個標準化資料表通常會對應到單一類別，而且不會使用與資料表之間的關聯性相同的方式來表示類別之間的關聯性。商務應用程式開發人員必須經常使用兩種以上程式設計語言：適用於商務邏輯層與展示層的高階語言 (例如 Visual C# 或 Visual Basic)，以及與資料庫互動的查詢語言 (例如 Transact-SQL)。因此，開發人員必須精通許多語言才能具有效率，而且也會在開發環境中產生語言不符的情況。例如，使用資料存取 API 針對資料庫執行查詢的應用程式會使用引號，將查詢指定成字串常值 (String Literal)。這個查詢字串對於編譯器而言是不透明的，而且不會檢查是否有錯誤，例如語法無效或它所參考的資料行或資料列是否實際存在。此外，系統無法提供查詢參數的型別檢查和 IntelliSense 支援。
實體架構 可讓開發人員處理網域指定之物件和屬性形式的資料，例如客戶和客戶地址，而不必考慮此資料儲存所在的基礎資料庫資料表和資料行。如需詳細資訊，請參閱 Entity Data Model。LINQ 可讓開發人員在其應用程式程式碼中撰寫以集合為基礎的查詢，而不需要使用不同的查詢語言。透過 實體架構 的物件服務基礎結構，ADO.NET 會將資料的常見概念性檢視 (包括關聯式資料) 公開為 .NET 環境中的物件。如此可讓物件層變成 LINQ 支援的理想目標。這個 LINQ 技術 LINQ 到實體 可讓開發人員針對 實體架構 物件內容建立彈性的強型別查詢，其方式是直接從開發環境使用 LINQ 運算式和 LINQ 標準查詢運算子。查詢是以程式語言本身表示，而非以內嵌於應用程式程式碼中的字串常值 (String Literal) 表示，在 Microsoft .NET Framework 2.0 版 上撰寫的應用程式通常是這個情況。編譯器將會找到語法錯誤以及成員名稱和資料型別的錯誤，而且會在編譯時期報告這些錯誤，以減少 實體資料模型 與應用程式之間可能發生的型別問題。
LINQ 到實體 查詢會使用物件服務基礎結構。ObjectContext 類別是以 CLR 物件形式與 實體資料模型 互動的主要類別。開發人員會透過 ObjectContext 建構泛型 ObjectQuery 執行個體。ObjectQuery 泛型類別表示傳回具型別實體之執行個體或集合的查詢。傳回的實體物件可以更新，而且會位於物件內容中。以匿名型別的成員形式傳回的實體物件也是同樣情形。
本節內容
- LINQ 和 Entity Data Model
提供 LINQ 和 實體資料模型 的概觀。
- HOW TO：在 Visual Studio 中建立 LINQ to Entities 專案
提供如何在 Visual Studio 中建立 LINQ 到實體 專案的相關資訊。
- 逐步解說：建立 Adventure Works Sales Model 和查詢 (Visual Basic)
提供複雜性最低的基礎端對端 LINQ 到實體 案例。
- 逐步解說：建立 Adventure Works Sales Model 和查詢 (C#)
提供複雜性最低的基礎端對端 LINQ 到實體 案例。