LINQ to Entities Overview

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Most business applications are currently written to access data in relational databases. At some point, these applications will have to interact with the data represented in a relational form. The relational model is optimized for efficient storage and retrieval, not for the conceptual modeling used in object-oriented programming. Multiple normalized tables often correspond to a single class, and relationships between classes are not represented in the same way as relationships between tables. Business application developers must often use two (or more) programming languages: a high-level language for the business logic and presentation layers (such as Visual C# or Visual Basic), and a query language to interact with the database (such as Transact-SQL). This requires the developer to be proficient in several languages to be effective, and also causes language mismatches in the development environment. For example, an application that uses a data access API to execute a query against a database specifies the query as a string literal by using quotes. This query string is opaque to the compiler and is not checked for errors, such as invalid syntax or whether the columns or rows it references actually exist. There is no type checking of the query parameters and no IntelliSense support, either.

The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to think about the underlying database tables and columns where this data is stored. For more information, see Entity Data Model. LINQ allows developers to formulate set-based queries in their application code, without having to use a separate query language. Through the Object Services infrastructure of Entity Framework, ADO.NET exposes a common conceptual view of data, including relational data, as objects in the .NET environment. This makes the object layer an ideal target for LINQ support. This LINQ technology, LINQ to Entities, allows developers to create flexible, strongly typed queries against the Entity Framework object context by using LINQ expressions and the LINQ standard query operators directly from the development environment. The queries are expressed in the programming language itself and not as string literals embedded in the application code, as is usually the case in applications written on the Microsoft .NET Framework version 2.0. Syntax errors as well as errors in member names and data types will be caught by the compiler and reported at compile time, reducing the potential for type problems between the Entity Data Model and the application.

LINQ to Entities queries use the Object Services infrastructure. The ObjectContext class is the primary class for interacting with an Entity Data Model as CLR objects. The developer constructs a generic ObjectQuery instance through the ObjectContext. The ObjectQuery generic class represents a query that returns an instance or collection of typed entities. The returned entity objects are updatable and are located in the object context. This is also true for entity objects that are returned as members of anonymous types.

In This Section

LINQ and the Entity Data Model

Provides an overview of LINQ and the Entity Data Model.

How to: Create a LINQ to Entities Project in Visual Studio

Provides information about how to create a LINQ to Entities project in Visual Studio.

Walkthrough: Create Adventure Works Sales Model and Query (Visual Basic)

Provides a fundamental end-to-end LINQ to Entities scenario with minimal complexities.

Walkthrough: Create Adventure Works Sales Model and Query (C#)

Provides a fundamental end-to-end LINQ to Entities scenario with minimal complexities.

See Also

Other Resources

LINQ to Entities