ADO.NET Entity Model and LINQ?

Since the EDM supports inheritance for entity types, the query language has to enable users formulate queries that look at the inheritance hierarchy of types. For example, our conceptual EDM schema has an entity type SalesOrder, and a subtype StoreSalesOrder that has some specific characteristics. Here, the IS OF operator checks to see if an expression ("o" in this case) is an instance of the type specified in parenthesis.

In addition to the various extensions in Entity SQL designed to provide a first-class query experience against EDM schemas, Entity SQL incorporates various enhancements that come from experience with more traditional SQL dialects. For instance, in Entity SQL expressions can yield scalars or collections, and collections are first-class constructs that can appear in most expression contexts, making them fully composable. For example, a collection can go in the FROM clause and act as the source for a query, or it can go in the SELECT list, which will result in one of the columns of the result-set being of a collection type instead of a scalar.

For an in-depth description of Entity SQL see eSQL in the references at the end of this document. The vast majority of new code for business applications is written in general purpose, object oriented programming languages such as Visual Basic and C#. These programming languages and their surrounding development environments model business entities as classes and their behaviors as code.

To contrast with this, ADO.NET so far has exposed data from databases as "values", that is, as rows and columns. In order to interact with databases, applications have to deal with the impedance mismatch that exists between the data and the application code; this includes both the way queries are formulated and the way results are exposed. The ADO.NET Entity Framework includes an object services layer that reduces, and often eliminates, this impedance mismatch.

Applications, particularly large applications or large systems made of several applications, can rarely use a single representation of the data across its entire code base; various aspects such as static versus dynamic knowledge of queries and result-set structure, user-application interaction model, etc. affect the way applications need to interact with the data in databases. Rather than introducing an entirely new, stand-alone infrastructure for exposing database data as objects, the ADO.NET Entity Framework includes an "object services" layer that integrates with the rest of the stack and exposes entity values as . NET objects as a presentation choice.

Regardless of whether you choose to consume your data as "values" (rows and columns) or as objects, you still use the same infrastructure; that is, the same conceptual EDM schema can use used, along with the same mapping and the same query language —Entity SQL. While this is nice for late-bound scenarios such as reporting and business intelligence, or for directly serializing results, for example, from a webservice, for the cases where heavy business logic needs to be written it's usually much better to have objects representing the business entities. Instead of using a command object to represent the query, we use an "object context" that acts as the entry point to the object services and a Query object that represents a query in the object space.