Programming Against the ADO.NET Entity Framework The ADO.NET Entity Framework raises the level of abstraction at which developers work with data. Rather than coding against rows and columns, the ADO.NET Entity Framework allows you to define a higher-level Entity Data Model over your relational data, and then program in terms of this model. You get to deal with your data in the shapes that make sense for your application and those shapes are expressed in a richer vocabulary that include concepts like inheritance, complex types, and explicit relationships. In his article, An Entity Data Model for Relational Data (parts I & II), Mike Pizzo explains the details of the Entity Data Model and how to map a model to a database. In this article, I discuss the capabilities the ADO.NET Entity Framework provides for programming against a model after it is defined. The material in this article is intended as an overview that covers the breadth of features available to developers. Each of these features is a topic unto itself and is covered in more detail in the MSDN documentation that accompanies the ADO.NET Entity Framework. Overview of the ADO.NET Entity Framework The ADO.NET Entity Framework is built in a layered architecture on top of existing ADO.NET 2.0 data providers. Figure 1 illustrates this layering. 
Figure 1: The ADO.NET Entity Framework is built in a layered architecture above the existing ADO.NET 2.0 data providers.The ADO.NET 2.0 Data Providers offer a common programming model for accessing disparate data sources. Whether you are programming against a Microsoft SQL Server database or an Oracle database, you use the same fundamental programming abstractions: a connection object, a command object, and a data reader object. The ADO.NET Entity Framework introduces a new data provider called EntityClient; this is the first layer above the ADO.NET 2.0 data providers. EntityClient offers the same programming abstractions as the other data providers-connections, commands, and data readers-but adds mapping capabilities that translate queries expressed in terms of the model into the equivalent queries in terms of the tables in the databases. To complement these capabilities, the ADO.NET Entity Framework introduces an extended query language called Entity SQL (E-SQL), which augments traditional SQL with constructs necessary for querying in terms of the higher-level modeling concepts in Entity Data Models (inheritance, complex types, and explicit relationships). Above the EntityClient layer, the ADO.NET Entity Framework includes an Object Services layer, which provides a programming model in terms of strongly-typed objects. At the Object Services layer, entities are represented as objects-instances of data classes that are mapped to the entity types in the model. The Object Services layer supports querying with both Entity SQL and Language Integrated Query (LINQ). Query results are manifested as objects whose properties can be read and set by application code. Object Services keeps track of changes made to the objects and can propagate these back to the database. The ADO.NET Entity Framework’s mapping engine performs the translation between changes to the entity objects and operations on the underlying database tables. | " |
The Object Services layer supports querying with both Entity SQL and Language Integrated Query (LINQ).
| " |
Developers can choose to program against either the EntityClient layer or the Object Services layer. This choice provides flexibility for different application scenarios. In cases where the application does not require objects, the EntityClient layer provides a lower-level entry point that offers the benefits of entities without the overhead of object materialization. When you require the convenience and change-tracking capabilities of objects, you can choose to work at the Object Services layer. In either case, an underlying ADO.NET data provider performs database operations and compensates for the differences between database systems. Thus, the ADO.NET Entity Framework exposes exactly the same programming model and query syntax, regardless of the particular DBMS in which the data is stored. In this article, I’ll approach the ADO.NET Entity Framework top-down: First I’ll show some code snippets that illustrate programming at the Object Services layer. Then, I’ll delve into some examples that show EntityClient in action. | & | | 
By: Shyam Pather
Shyam Pather is a Senior Development Lead on the Data Programmability Team at Microsoft, currently focused on building the first release of the ADO.NET Entity Framework. Shyam began his career at Microsoft in the Windows Networking team, working first on network driver infrastructure and then on the first two releases of Universal Plug and Play in Windows. Shyam joined the SQL Server team to work on an incubation project that eventually became SQL Server Notification Services. After shipping two releases of that product, Shyam started in his current role on ADO.NET. His team delivers key parts of the object-relational mapping technology on which the ADO.NET Entity Framework is based.
spather@microsoft.com | Fast Facts | | The ADO.NET Entity Framework allows you to program in terms of a high-level conceptual model of your data. This eliminates much of the need for custom data access layers. | |
|