Is the ADO.NET Team Abandoning LINQ to SQL?
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.
Update May 23, 2008: Andres Aguiar agreed with my conclusion in his comment to this post, but stated:
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. :-(.
Atom 1.0 site feed
16 comments:
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 C# team looks to be thinking about functional programming now.
The Data Programmability will always be thinking about data. That's why the EF is the safe choice.
Don't forget that SP1 to .NET 3.5 is not RTM yet so there's still to see changes to LINQ to SQL but I agree that there's definitely been a void of information lately.
If LINQ to SQL is becoming a legacy API, it's just about the right to start profiling the performance of EF - let's see some number Joe (and we both did benchmarks of LINQ to SQL during betas so don't let the EF team get off the hook).
With regards
Anders Borum / SphereWorks
This would be a huge problem as we are just investing a lot in LINQ 2 SQL under the assumption that the missing pieces will be delivered at some point in the future. It would be very hard to convince my boss to go the EF and invest again a lot of time to get to know that technology, but it would also be very hard to develop v2 of our application in a few years when we still do not have things like synchronisation of LINQ diagrams (dbml files). If they were to abandon LINQ 2 SQL it would leave a very bitter taste in our mouths.
If this happens, I am no longer going to invest any time into learning new MS technologies until they have been mainstream for 2-3 years.
@Andres,
The SQL Server Data Programmability group took over ownership of LINQ to SQL from the C# group in mid-October 2007. See the update of 5/23/2008 to the post.
We just added LINQ to SQL to our architecture, EntitySpaces. If this is true it will be bad news for Microsoft. Perhaps it is an attempt to make sure 3rd parties cannot leverage LINQ to build competing architectures. They already removed some things in the LINQ to SQL beta's like retrieving a DataTable that make it much harder for us to operate.
I think they are probably realizing there are some sharp folks out there that can take there that can use their own weapons against them to a greater success than they imagined.
I know this is just a rumor, and despite the title of the post I don't think it offers any evidence at all, but still, the very thought of it ticks me off.
Mike Griffin
EntitySpaces, LLC
While on the topic of EF, does anyone here happen to know if it is possible to use the DataContractJsonSerializer on EF EntityObjects? I think the answer is "no" but wanted to confirm.
Thanks.
Okay, I had to look up "demurrer" and now I'm laughing. "a legal objection that admits the facts of an opposing argument but asserts that those facts alone are not adequate to make the case"
"IANAL" he says. uh huh... :-)
Julie (she of rose-colored glasses)
@Julie,
I originally wrote "Julie Lerman Demurs" but thought you'd like "Julie Lerman's Demurrer" better (even though it's a bit of a stretch of the term.)
DamienG says "Short answer: No."
http://www.dotnetkicks.com/adonet/Is_the_ADO_NET_Team_Abandoning_LINQ_to_SQL
Further proof: no mention of the released-with-3.5 LINQ to SQL in the prep guide for the upcoming ADO.NET 3.5 certification exam, but there's a full section on the released-post-3.5 entity framework. DUMB.
LINQ to SQL concepts and objectives are by-and-large a subset of EF. No matter what anyone says today, from a natural progression standpoint it's inevitable that one will subsume the useful elements of the other and the other will be dropped. Given the investment in and higher-level capabilities of EF, it only makes sense that EF will subsume L2S. Consider for a moment the opposite -- that L2S subsumes EF -- it's clearly ridiculous.
@jens:
Bitter taste in *your* mouth? Get in line... Some of us spent a couple years of our lives on LINQ to SQL.
I for one use it on my projects, and EF isn't going to make it stop functioning. :)
@Mike Griffin:
No, it's not some conspiracy to prevent people from using LINQ to SQL. Things in betas that were removed by RTM were removed for very good, sound reasons, not the least of which involved cost. Never in my time there was there *any* comment about removing a feature to make life difficult. Indeed, LCA would probably have broiled our hides had such a plan been put forward. Please temper your paranoia with practicality.
And re-read Matt's comment.
Finally a statement from Microsoft on EF vs L2S:
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
(...it appears to have been published as a response to this thread:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1
)
I recommend you take a look at Mono's reimplementation of Linq-To-SQL:
http://code.google.com/p/dblinq2007/
The latest official release was in 2008, but from the SVN logs, there has been a lot of development/expansion. In particular, it supports both XML and attributed mappings, and a number of database engines:
- SQL Server
- SQL CE
- Oracle
- MySQL
- SQLite
- PostgreSQL
- Firebird
- Ingres
The classes are drop-in replacements for Microsoft's classes, and the open source license allows usage in commercial products. Best of all, when you're (inevitably) trying to figure out why a complex Linq expression is failing, you have tracing capabilities and full source code.
So this is an interesting alternative to hoping that Microsoft will maintain Linq-To-SQL (or one day evolve the Entity Framework into something that simplifies rather than complicates coding).
its pretty much interesting it training
Post a Comment