I’ve just returned from Carl Perry’s Tech Ed session on the Entity Framework, an object-relational library for ADO.NET, initially implemented for SQL Server. Perry is a Senior Program Manager Lead on the SQL Server team. The Entity Framework is the first implementation of what Microsoft calls the Entity Data Model. Generate a data model from a database, tweak the model in Visual Studio’s designer, then generate code to use in combination with LINQ (Language Integrated Query). I found this code snippet from Perry’s slides illuminating:

using (AdventureWorksModel model = new AdventureWorksModel())
{
var query = from c in model.Customer
where c.MiddleName == null
select new {
FirstName = c.FirstName,
LastName = c.LastName,
EmailAddress = c.EmailAddress }; 

foreach (var c in query)
 {
 Response.Write(String.Format("<p>{0}\t{1}\t{2}</p>",
 c.FirstName,
 c.LastName,
 c.EmailAddress));
 }
}

In the above code, AdventureWorksModel is an instance of an Entity Framework model, and as you can see makes for clean strongly-typed coding against the database.

But doesn’t Microsoft already have a shiny new object-relational layer called LINQ to SQL? Why bother with Entity Framework?

There appears to be considerable overlap, but the Entity Framework has higher ambitions. Perry said that LINQ to SQL is fine when your entities map closely to database tables, but Entity Framework is better for more complex mappings. It is not there yet, but it looks as if Microsoft will evolve the framework to enable model-first development and add features like the ability to define constraints in the model. All very familiar in the modeling world. The question may become: why bother with LINQ to SQL?

Entity Framework is not new; for example it is described in this paper from 2006. However, I had not looked at it before in any detail. You can download a beta here.