Introducing the ADO.NET Entity Framework
The ADO.NET team has a new technology brewing that aims to raise the level of abstraction at which applications perform data access:
Entity Framework. Expected around the middle of the year, it provides a mechanism via which you can define a conceptual model on top of a database schema and then program against that model. The model is often referred to as the Entity Data Model (EDM).
The Entity Framework is a provider-based mechanism meaning that it has the potential to work with non-Microsoft databases just like ADO.NET has done since its inception. The central idea of the Entity Framework is that the schema of your relational database may not be something that you want to surface directly to application programmers. One common case would be one where the schema is a little “less than optimal” and you’d like to tidy it up a bit for application access. Another case might be where the schema is highly normalised and hence not ideal for an application developer who is used to object oriented programming models.
In order to surface the EDM to an application developer, the Entity Framework needs three different groups of metadata:
1. The EDM itself. This is modelled using an XML grammar known as
Conceptual Schema Definition Language (CSDL).
2. The definition of the underlying database schema. This is modelled using an XML grammar known as
Store Schema Definition Language (SSDL).
3. A mechanism via which the framework is to translate (1) into (2) and vice versa. This is modelled using
Mapping Schema Language (MSL).
In terms of programming the Entity Framework, we pass the metadata (CSDL+MSL+SSDL) to the object model and it surfaces the defined EDM in one of two ways:
1. Using the traditional ADO.NET data access API. There is a new EntityClient provider that has EntityConnections, EntityCommands and EntityDataReaders. The EntityClient executes queries written in a database neutral query language known as
Entity SQL.
2. Using an Object Relational Mapping API that ships as part of the Entity Framework. This supports building queries using LINQ, so it is usually referred to as “
LINQ to Entities”.
As a simple example, we might have a DB2 store with a table called Customers which we map into conceptual entity sets: “Customers” and “PriorityCustomers”. A developer can then write a LINQ query against those entity sets without needing to write any SQL or being exposed to the underlying store schema!
There’s a lot of promise in V1.0 of the Entity Framework. If you want to find out more, I’d encourage you to
download the Beta 3 build.
If you’d rather someone else did that work then I can take you through it :-) – just come along to the
UK MSDN Roadshow.
Mike Taulty
Read Mike's blog
