Thu, Jun 22 2006 12:58 AM
Erwyn van der Meer
ADO.NET Entity Framework CTP planned for later this summer
[Update 2006-06-22: Microsoft's Pablo Castro from the ADO.NET team posted a comment on my blog in which he indicates that a first ADO.NET vNext CTP is to be expected around August 2006. That is quite a bit sooner than what I expected based on "before the end of this year". I've updated the title of this post to reflect this. Pablo also writes that the LINQ integration work is further along than I thought: IQueryable<T> is already implemented for the ADO.NET Entity Framework and LINQ for Entities does not use Entity SQL as an intermediate step. The problem of LINQ to SQL versus LINQ to Entities remains, so I have left my blog post below unchanged.]
Today Microsoft's S. "Soma" Somasegar blogged about LINQ and ADO.NET innovations. In his blog post he announces the names for various LINQ variants. For DLinq and XLinq this means a name change. The new names started to appear a little over a week ago. Soma separates the LINQ variants into two categories:
Filed under: .NET
LINQ to ADO.NET, which includes:
LINQ to DataSet
LINQ to Entities
LINQ to SQL (formerly DLinq)
LINQ support for other data types include:
LINQ to XML (formerly XLinq)
LINQ to Objects
LINQ is already very real in CTP form since September 2005. The latest is the May 2006 CTP. But the ADO.NET Entity Framework currently only has a public appearance in two whitepapers. Soma ends his post with "keep an eye out for a preview of the Entities work before the end of this year". I guess, this is Microsoft-speak for "don't expect any bits before the end of December 2006" since Microsoft has a tendency to overrun announced dates. Remember, how the beta 2 of "Whidbey" was to be released in the first quarter of 2005, but didn't arrive until something like March 48, 2005 (i.e., April 17, 2005 ;).
Hopefully the upcoming six months gives Microsoft enough time to get their future data access story straight and realign the disparate data access technologies LINQ to Entities and LINQ to SQL.
Currently LINQ to Entities appears to be bolted on the ADO.NET Entity Framework as an afterthought. And as OR/Mappers, LINQ to SQL and the Entity Framework to some extent do the same thing, yet in very different ways.
Without even seeing ADO.NET vNext bits, these "conflicts" are visible in the docs as silly differences like a "SubmitChanges()" method versus a "SaveChanges()" method. And we don't need two different XML syntaxes for describing mappings between tables and entities. And Microsoft please don't release two different GUI tools for creating those mappings.