The ADO . NET Entity Framework and Entity Data Model

The ADO . NET Entity Framework and

Entity Data Model

Microsoft ’ s ADO.NET team began designing the Entity Framework (EF) and Entity Data Model (EDM)

near the date in 2003 when the C# 3.0 design group decided to develop a LINQ to SQL extension as a

“ stand - in ” for the abandoned ObjectSpaces O/RM tool project. The two projects progressed in parallel,

apparently with little or no communication between the two groups. In early 2006, the ADO.NET team

gained ownership of the LINQ to SQL and LINQ to DataSet implementations and added LINQ to

Entities as an optional method for executing queries over the EDM. The ADO.NET group presented

several sessions at Tech * Ed 2006 and published a series of whitepapers about EF and EDM in June 2006.

The “ Next - Generation Data Access: Making the Conceptual Level Real ” technical article by Jos é Blakeley,

David Campbell, Jim Gray, S. Muralidhar, and Anil Nori, proposed to extend the EDM from basic CRUD

operations to reporting and analysis services (business information) and data replication.

You can read the preceding technical paper at http://msdn2.microsoft.com/en - us/

architecture/aa730866(vs.80).aspx and its companions, “ The ADO.NET Entity Framework

Overview ” at http://msdn2.microsoft.com/en - us/architecture/aa697427(VS.80)

.aspx and “ ADO.NET Tech Preview: Entity Data Model ” at http://msdn2.microsoft.com/

en - us/architecture/aa697428(VS.80).aspx .

EF is a much more than an O/RM tool. EF provides a complete set of data services including:

Query services

ClientView services

Persistence services

Object services

EF is the first concrete implementation of the EDM and enables developers to abstract the physical

storage schema of relational databases to a conceptual schema (also called a conceptual layer or conceptual

model) that conforms to the entity - relationship (E - R) data model. Dr. Peter Chen proposed the E - R data

model in a 1976 paper, “ The Entity - Relationship Model — Toward a Unified View of Data, ” which you

can read at http://bit.csc.lsu.edu/

˜

chen/pdf/erd.pdf . E - R became a mainstay of data

modeling for relational databases and the foundation for many computer - aided software engineering

(CASE) tools.

The E - R model is independent of the underlying relational database management system (RDBMs) or

data retrieval and update language, syntax or dialect, but an SQL flavor is assumed. Microsoft says that

EF “ is an execution runtime for the for the E - R model ” that ’ s RDBMS - agnostic. As you would expect,

SQL Server 200x and SQL Server Compact Edition (SSCE) have SqlClient - derived EntityClient

data providers for EF v1.0. When this book was written, IBM DB2, IS, and U2, as well as Oracle,

MySQL, and SQLite supported EF with custom EntityClient data providers for .NET. The

EntityClient object provides EntityConnection , EntityCommand , EntityParameter and

EntityDataReader objects. EntityClient has its own query language, Entity SQL (eSQL), which is

related to SQL but has entity - specific extensions. eSQL v1 has no data management language (DML)

constructs for INSERT , UPDATE or DELETE operations. Microsoft promises to implement entity -

compatible DML in a future version.

An EDM EntityType specifies an object in the application domain that is represented by data. An

EntityObject is an instance of an EntityType , has one or more Properties , and is uniquely

identified by an EntityKey . Properties can be of SimpleType , ComplexType or RowType . An

EntitySet contains multiple EntityObject instances, an EntityContainer holds multiple

EntitySet s, and corresponds to the database (such as Northwind) at the physical data store layer and

schema (such as dbo) at the conceptual level. A RelationshipType defines the relationship of two or

more EntityType s as an Association , which is a peer - to - peer relationship or Containment , that

specifies a parent - child relationship. The top - level EDM object is a Schema , which represents the entire

database.

Following are some of the most important benefits of implementing EDM in data - intensive .NET

projects:

Generates a data access layer that isolates the data domain from the application domain

Handles relational database vendor or schema changes without the need to alter C# or VB

source code and recompile the project

Enables the business logic layer to work with real - world business entities, such as customers,

orders, employees, and products, rather than rows and tables of relational databases

Supports complex properties, such as PhysicalAddress, which might include Street1, Street2,

City, State, ZipCode, Country and Coordinates, and PostalAddress, which might include only

PostOfficeBox, City, State, PostalCode and Country.

Models object - oriented concepts such as inheritance and hierarchical (nested) or polymorphic

resultsets, which don ’ t fit the relational model

Exposes relationship navigation properties to eliminate the need for complex joins between

related tables

Provides an advanced, graphical EDM Designer to simplify inheritance and hierarchy models

and enable incremental changes to mapping files

Maps the conceptual layer ’ s entity model to an object model in the Object Services layer with an

ObjectContext for identity management and change tracking

Enables simple, strongly typed queries with Object Services ’ LINQ to Entities implementation

It ’ s important to bear in mind that EF isn ’ t a traditional O/RM tool and using the Object Services layer

and LINQ to Entities is optional. Mapping to objects occurs at the conceptual layer, so the term object/

entity mapping tool might represent a more accurate description. Where performance is critical, such as

with reporting and analysis services, you can opt to write eSQL queries and return conventional,

untyped DataReaders based on the conceptual layer ’ s schema.