Thursday, June 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:

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.

Filed under:

# re: ADO.NET Entity Framework CTP planned for later this summer

Thursday, June 22, 2006 6:23 AM by davidacoder

I believe the right way to look at this is to see LINQ to SQL not as an ORM thing. ORM typically map between a database structure and an object layer. But what you get from LINQ to SQL are really exact equivalents of the stuff you have in the database. Just think of it as bringing the concepts of a relational DB as first class citizens into the CLR world. LINQ to SQL doesn't change your app architecture a bit. It only replaces ugly database access code (with SQL commands in strings, lots of type conversion stuff etc) into beautiful database access code. But the concepts you deal with when you use LINQ to SQL are database concepts: tables, rows, foreign keys, joins etc.

I believe having the two is a good choice. There are lots of apps that don't need or want anything that maps to entities. They want to program against the DB. Why should they not have a better syntax for that, i.e. LINQ to SQL?

I only hope that some of the more advanced things in LINQ to SQL will be taken out, like inheritence etc. I believe that if LINQ to SQL only brings database concepts as first class constructs into the CLR, it makes sense. If it attempts to be a full fledged ORM product, there is indeed a lot of overlap with the entities stuff.

# re: ADO.NET Entity Framework CTP planned for later this summer

Thursday, June 22, 2006 11:54 AM by Erwyn van der Meer

@davidacoder. I think the goal for LINQ to SQL (aka DLinq and ObjectSpaces before that) was definitely to build an OR/Mapper. From the DLinq Overview article I quote:

"DLinq, a component of the LINQ Project, provides a run-time infrastructure for managing relational data as objects without giving up the ability to query. It does this by translating language integrated queries into SQL for execution by the database and then translating the tabular results back into objects you define. Your application is then free to manipulate the objects while DLinq stays in the background tracking your changes automatically."

"DLinq applications are easy to get started. Objects linked to relational data can be defined just like normal objects, only decorated with attributes to identify how properties correspond to columns. Of course, its not even necessary to do this by hand. A design-time tool is provided to automate translating pre-existing relational database schemas into object definitions for you."

I understand your point that LINQ to SQL should be kept simple. In that way it may co-exist with LINQ to Entities, which will have its place for more advanced scenarios. For example, by cutting out support for inheritance. Microsoft has not yet announced what the future plans for LINQ to SQL are. We will have to wait and see.

# re: ADO.NET Entity Framework CTP planned for later this summer

Friday, June 23, 2006 12:59 AM by davidacoder

Yes, you are right. It was probably more a "this way it would make sense to have both" comment from me ;)

# ADO.NET vNext - feedback so far

Friday, June 23, 2006 9:46 PM by Data Access blog

Since announcing our ADO.NET vNext plans at TechEd last week, the team has been on the lookout for your...

# ADO.NET vNext - feedback so far

Tuesday, July 11, 2006 10:31 AM by ADO.NET team blog

(this post&amp;nbsp;was originally posted here)

Since announcing our ADO.NET vNext plans at TechEd
...