It's common for Microsoft to deliver a substandard 1.0 product, a mediocre 2.0 version and eventually by the time 3.0 comes along, they've delivered a something decent. Let's look at Microsoft's long history in the ORM space:
2001 - ObjectSpaces was to be a great addition to the .Net ecosystem. Somewhere between 2001 and 2005, Microsoft integrates ObjectSpaces with WinFS: the mother of all query technology. In 2005 the entire WinFS project is shelved, taking our ObjectSpaces dream with it.
2007 - LINQ to SQL would save the day (but only if you were using SQL Server.) After much hype, and barely a year after it RTM’d, Microsoft announced in October of 2008 that LINQ to SQL was dead. The Entity Framework is proclaimed to be the future of .NET data access technologies.
2008 - Entity Framework v1.0 makes it's glorious debut. And it's unanimous - it is not what developers wanted or asked for. Too many bugs, limitations, missing features, and lack of support for n-tier development.
2009-2010 - Entity Framework v4.0 (or v2.0, but who's counting anyway.). Still missing features, and still buggy designer (as of Beta 2.) We finally get n-tier support by way of self-tracking entities.
This timeline clearly shows Microsoft has a terrible track record in delivering and supporting an object-relational mapping technology. I maintain the vote of no confidence for the Entity Framework as a whole, given that we, the enterprise architects & developers:
In my next post I'll provide details on the shortcomings of the Entity Framework v4.0.
Comments
Entity Framework comment
Hello Giorgio, I followed to this web site from your comment on InfoQ. I have tried using Entity Framework (.NET 3.5 SP1) to convert some Transact-SQL statement to "LINQ to Entity". The experience isn't very happy.
You will notice there is no explicit syntax for "left outer join" or "right outer join" in LINQ syntax. We have to work around such scenario ourselves, creating hard to read code.
Then, I tried to run some LINQ code inside a loop (it should be translated to Transact SQL's SELECT statements). I tried to catch the SQL statements in SQL Profiler, I found each batch of SELECT statement was slightly different in the local variable name being declared (EF will generate a block of statement being used by sp_executesql). They should have created exactly the same SQL statement for each iteration. Making each batch different woudl defeat SQL Server's execution plan caching ability.
This is just my observation of EF (in .NET 3.5 SP1).
Thanks,
Tony