Updated 5/23/2008 at the end of the post.
Danny Simmons' Why use the Entity Framework? post includes an "Entity Framework vs. LINQ to SQL" topic that lists the following advantages of Entity Framework (EF) over LINQ to SQL:
- Full provider model with support for multiple RDBMSs, including SQL Server Compact.
- Not tied to a one:one relationship between entities and database tables.
- Support for Table per Class and Table per Concrete Class hierarchy models.
- Support for entity-splitting and complex types (also called value types)
Missing from this list are, for starters:
- Default support for serializing complete object graphs.
- An out-of-the-box multi-tier story for SP1.
- Support for SQL Server Compact 3.5 SP1 in the Object/Relational Designer.
I had expected LINQ to SQL SP1 to support bidirectional serialization for WCF service applications with SP1's updated DataContractSerializer. However, the Object/Relational Designer's Serialization property still has None and Unidirectional options only. This fix would have taken minimal development and test time. You can accomplish this yourself but refreshing the data model requires adding [DataMember] attributes by hand to Association classes that create cyclic references.
LINQ to SQL has a much lighter footprint than EF, which makes it a better match for applications that use SQL Server Compact (SSCE) 3.5 SP1 and later. Support for SSCE by SqlMetal.exe arrived just in time for VS 2008 RTM but not by the designer. Surely there was plenty of time between VS 2008 RTM and SP1 Beta to work out this fix.
I also was looking forward to an early version of the mini connectionless DataContext that Matt Warren promised, as noted in my Changes Coming to LINQ for SQL post of just less than a year ago.
Compare LINQ to SQL SP1's New Features with Other ADO.NET Members
According to the ADO.NET Team's What's New in the SP1 Beta for LINQ to SQL? post of May 14, 2008, the following tweaks are what's new:
Across the LINQ to SQL we have made numerous bug fixes, better SQL translation for queries comparing nullable columns in Visual Basic, and support both in the runtime and the designer for SQL Server 2008.
New SQL Server 2008 Support includes:
- Support for connecting to SQL Server 2008 databases in Server Explorer
- Drag & drop tables in SQL Server 2008 databases from Server Explorer
- Support for the following new types: Date, Time, DateTime2, DateTimeOffset, Filestream
SqlClient class members contain the majority of SQL Server 2008 support modifications and the SqlClient update is required to deliver Katmai support for SqlDataReader 3.5 across the entire Microsoft product line.
EF and the Entity Data Model Designer received a raft of new and improved features, as did ADO.NET Data Services (Astoria), which turned into a framework between November 2007 and May 2008. Astoria currently is staffing up for v2, as evidenced by their Interested in working on the ADO.NET Data Services Framework (aka "Astoria") or XML? post of May 17, 2008.
It's obvious to me that only trivial resources were devoted to LINQ to SQL in the post-RTM period.
Is LINQ to SQL a Legacy Data Layer?
If Microsoft intends to end-of-life LINQ to SQL, the ADO.NET team should notify .NET developers. In the meantime, I'm adding the following caveat to my reasons to choose EF over LINQ to SQL:
- Entity Framework is Microsoft's strategic data access layer. LINQ to SQL has [almost | already] gained legacy status due to lack of attention from the Data Programmability group.
The Data Programmability Team never owned LinQ to SQL, it was owned by the C# team. That's why we have two O/R mappers, both teams wanted to ship theirs.
The Data Programmability team gained ownership of LINQ to SQL from the C# team about the time that Tim Mallalieu of SQL-DP took over program management from Dinesh Kulkarni, as Dinesh mentioned in his October 15, 2007 LINQ to SQL: What is NOT in RTM (V1) swansong from the LINQ to SQL team. (That's the post containing the source of the no "out-of-the-box multi-tier story" quote above.)
Tim doesn't qualify as a "great communicator." The last post to his blog was Databinding with ADO.NET Entity Framework is dated November 11, 2006. According to his LinkedIn profile, he's still employed by Microsoft as a Lead Program Manager.
Julie Lerman's Demurrer
Julie disagrees in her Damien Guard joins the LINQ to SQL team as a developer post of May 23, 2008. She says, "I have even seen suggestions that LINQ to SQL was intentionally cobbled and done so for political, not technical reasons." Me, too.
Matt Warren, the outspoken architect of LINQ to SQL, says in his Mocks Nix - An Extensible LINQ to SQL DataContext post of May 4, 2008:
LINQ to SQL was actually designed to be host to more types of back-ends than just SQL server. It had a provider model targeted for RTM, but was disabled before the release. Don’t ask me why. Be satisfied to know that is was not a technical reason. Internally, it still behaves that way. The trick is to find out how to swap in a new one when everything from the language to the runtime wants to keep you from doing it. [Emphasis added.]
(Matt gained his reputation for "telling it like it is" with his The Origin of LINQ to SQL post of May 31, 2007 which recounted the demise of ObjectSpaces in the black hole of WinFS and described his three years after the event as a "political nightmare.")
Julie interprets the hiring of Damien Guard by the ADO.NET Team as "an indication that the product will continue to evolve." I'm not so sure; Damien might have been hired to replace a dev lost to turnover in the ranks. The real money's being spent on the Entity Framework and its chief client, ADO.NET Data Services.
My thanks go to Julie for describing the original version of this post as a "deeply analytical blog post." For whatever it's worth, IANAL (I am not a lawyer) nor do I have any interest in being (or imitating) one. ;-) Full disclosure: I was a draftee on a Federal Grand Jury for a year and a half some time ago. :-(.