Friday, August 03, 2007

Mike Taulty Compares LINQ to SQL and LINQ to Entities

Apparently, Mike's recent vacation recharged his batteries because he's kept the promise he made in his June 22, 2007 blog.Suspend() post. He's moved on from his previous exhaustive coverage of LINQ to SQL to the more challenging task of analyzing the Entity Framework (EF) and LINQ to Entities.

Mike's August 3, 2007 LINQ to SQL/LINQ to Entities post contrasts LINQ to SQL and LINQ to Entities with the following basic premise:

LINQ to SQL is very much a consumer of ADO.NET in that it fits into the existing ADO.NET picture by sitting on top of the SQL provider (SqlClient).

The Entity Framework is a different beast in that it plugs in new bits to ADO.NET. It adds a new provider (the Entity Provider) altogether and a new language that this provider understands (Entity SQL). So, you can expect to see EntityCommand, EntityDataReader, EntityAdapter and so on.

The unusual thing about this new provider is that it's a layered provider in that its job is to sit above existing providers.

He then goes on to diagram the flow from a LINQ to Entities query expression as an Entity SQL (eSQL) command tree to an Entity Provider that translates the eSQL to the database's SQL dialect (e.g., T-SQL, PL/SQL, DB2 SQL.) Mike describes the process:

Regardless of the correctness of the [diagram], we've got a query captured as an expression tree from a LINQ perspective and then that needs to be turned into what I'd call a conceptual command tree which is a transformation from the LINQ query to an Entity Provider query dealing with the conceptual and then there's a transformation from that to a logical command tree which is then handed to the "real" provider which generates the right kind of SQL for that thing.

Based on my understanding of database-specific EntityClient providers, Mike's narrative sounds right to me, although I believe that Microsoft calls the conceptual command tree the Canonical Query Tree (CQT). There's more about QCTs and their role in query processing in Murali's August 21, 2006 Queries in ADO.NET vNext post.

An Earlier Attempt to Diagram Data Flow in the Entity Data Model

For reasons unknown, Microsoft has never published an official, detailed data-flow diagram for the EF and Entity Data Model (EDM). The Microsoft Patent Application for the Entity Framework and EDM includes several simplified diagrams (with extreme overuse of the term "rich") but nothing one could use to better understand how EF, EDM and LINQ to Entities interact.

I made a stab at diagramming the EF and EDM for my "Objectify Data With ADO.NET vNext" article in the October 2006 issue of Visual Studio Magazine. The article was based on the ADO.NET vNext August 2006 CTP, which predated the ADO.NET team's replacement of DataProviders with Entity Providers use of the term EntityClient.

Courtesy of 1105 Media, Inc.

Changing the System.Data.SqlClient Data Provider to an EntityClient Provider for SQL Server 200x legend and changing the T-SQL to eSQL legend on the arrow between the Map Provider Layer and the Data Provider box might bring this diagram into closer alignment with today's EF and EDM implementation. Comments, suggestions or both from Danny Simmons,  Zlatko Michailov, or both would be appreciated.

What Entity Framework Pilgrims Need from Microsoft

Prior to Tech*Ed 2007, I made a list of what I believed was needed from the ADO.NET Team for the delayed and orphaned Entity Framework to gain any traction at all with developers of data-intensive .NET projects. I published the list in a May 29, 2007 Defining the Direction of LINQ to Entities/EDM post to which Microsoft's Mike Pizzo responded with a detailed comment.

So here's another request: Mike Taulty and I currently must guess at our data flow diagrams. It's more than about time for Microsoft to publish a detailed, annotated EF/EDM/LINQ to Entities data flow diagram with the proper names of the components. Diagrams that illustrate how EF integrates with Projects Jasper and Astoria (and why) would be useful, too. 

Note: The diagrams in John Papa's ADO.NET Entity Framework Overview in MSDN Magazine's July 2007 "Data Points" column don't provide sufficient detail. However, his column does provide a summary of the Orcas Beta 1 version's features.

So far, I'd give the ADO.NET team a "C" or lower grade for responding to my requests. The Entity Framework June 2007 CTP was useful, despite its inability to run on Orcas editions other than Web Developer Express. (See my Entity Framework June 2007 CTP Visual Basic Samples post for example eSQL queries with results in DataGrid controls.)

Danny Simmons "June" CTP of the Entity Framework is finally out provided a detailed list of new features in the CTP, but he hasn't added a post in a month. He did say in an Orcas Beta 2!!! thread in the ADO.NET Orcas forum: 

Since the Entity Framework is now shipping separately from Orcas, the Orcas beta 2 does not include any Entity Framework bits, and unfortunately the existing CTP will also not work with beta 2.  We will, however, have a beta version of the entity framework sometime in August that will work with beta 2 (and have some additional goodies <grin>).

However, it's August 3 and there's nothing official so far in the ADO.NET Team Blog about the forthcoming EF CTP or Beta, and not even a hint from Danny whether this drop will finally include a preview of the long-awaited EDM Designer.

Update 8/3/2007 1630 PDT: Mike Pizzo responds in a comment to this post.

Update 8/8/2007: Mike Taulty updated his post with these EF observations:

[If] you have a 1:1 mapping between the conceptual model and the logical model you can simply pass the tree on unaltered. That's kind of neat and I don't suppose it's by accident :-)

I'm reading quite a bit about Entity Framework at the moment and it's causing me headaches :-) [Emphasis added.]

Me, too.

Following are links to a few recent OakLeaf posts about EF, EDM and LINQ to Entities in reverse date sequence:

Update 8/4/2007 0630 PDT: EF Beta 2 release in August is official. From Elisa Flasko, ADO.NET Team program manager in Entity Framework Beta 2:

As promised, we will have Beta releases of the Entity Framework that correspond to the Beta 2 and RTM releases of Orcas. A Beta 2 release of the Entity Framework that works with the recent release of Orcas Beta 2 will be available later this month, along with a list of the new features available in that release.

Pablo Castro says We'll host an experimental Astoria data service for you. Mike Flasko,
Astoria Program Manager, is offering free "in-the-cloud" storage of relational databases up to 100 MB in size and providing RESTful CRUD features. I'm considering putting the 50MB version of my "OakLeaf University" sample database up there.


Michael Pizzo said...


As usual, your summary of the Entity Framework (despite our apparent best attempts at under-documenting the architecture) are unusually accurate.

One small change in your diagram; while the application can issue eSQL queries at either the Object Services or Mapping Provider (now renamed “EntityClient”) layers, the communication between layers is always done through CQTs. So Object Services generates a CQT from either the LINQ expression or the eSQL query and passes that CQT to the EntityClient. The EntityClient expands the CQT using the mapping views and passes the expanded CQT (not T-SQL) to the store data provider (i.e., SqlClient). As Mike correctly describes in his post, only the provider knows how to generate provider-specific syntax from the canonical CQT representation.

This architecture is designed to be symmetric such that, in the future, for default mappings, the EntityClient could be removed and the ObjectServices layer could talk directly to the underlying provider.

Also, note that we didn't rename "Data Providers" to "Entity Providers", the only rename was to change the "Mapping Provider" to "EntityClient". Other providers (i.e., "SqlClient Data Provider") remain unchanged.

Mike's summary is scarily accurate, though that doesn't excuse us from posting something. I'm working on such a posting now...


--rj said...


Glad to hear additional documentation is coming. I'm sure Mike Taulty will appreciate it, too.