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.
LINQ to Entities is a more complex abstraction because it tries to insulate you from the physical representation of your persistent store. This does give you the ability to re-architect the store, or use a range of technologies.
The price is the additional complexity, in particular the need to understand EQL as opposed to SQL as the language into which queries are translated first, which may make determining things like performance characteristics hard.
In addition LINQ to Entities won’t support persistent ignorance for its first release, which means it won’t play nicely with Test First approaches.
So I would suggest start with LINQ to SQL, and if it does not meet your needs, then look towards LINQ to * where that includes LINQ to Entities but also proposed ideas like LINQ to NHibernate.
It’s also important to separate the idea of lINQ from the underlying providers of ORM in LINQ to SQL and LINQ to Entities. LINQ is a language syntax ‘to SQL’ and ‘to Entities’ are providers of IQueryable implementations and API’s for data access
Is it DBMS indepedent?
All you need, apparently, is an Entity Framework Provider. Apparently IBM already has a preview of one for DB2, and others will follow.
Tim
I’m surprised that Microsoft have produced this as it seems to me to be targeted at the MDA market. MS don’t have much in the way of MDA modelling tools, and MDA itself has promised much but seems to have delivered little in productivity gains. Or perhaps it’s just me being too cynical again.
Clyde,
It could go in that direction, but it is not strictly MDA since you cannot do model-first development. You actually have to start with the database, which is possibly back-to-front from a theoretical point of view, but there are plenty of people with databases that they want to publish.
It does look more productive than other model-driven tools I have looked at. It does not attempt to write an app for you.
Tim
Good (and perspicacious) point. As always. 🙂
@Clyde: MS is targeted to the MDA market too, but they call it Software Factories.