As the PCD2008 hangovers wore off the announcements of the week were overshadowed by the apparent axing of LINQ to SQL. It all started with a post by Tim Mallalieu, where he stated :
We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios. We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
A furore broke out after Ayende observed that the 'management speak' from Microsoft had effectively killed LINQ to SQL. Similar posts and comments across the .net development community prompted a post by Microsoft in order to Clarify(ing) the message on L2S Futures. Where Tim, it seems to me, made very sure that it would good to put the final nail in the LINQ to SQL coffin by 'clarifying',
We will continue make some investments in LINQ to SQL based on customer feedback. <snip>
We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.
So Microsoft is starting to be more official about the end of LINQ to SQL, which should come as no surprise - they have been saying this for a long time. Back in April 2007 in a post about Microsoft's Data Access Strategy, the idea that LINQ to SQL was an interim for moving to Entity Framework was already made clear.
LINQ to SQL is targeted at rapid-development scenarios against Microsoft SQL Server and provides a simpler approach and richer design experience in the Orcas timeframe for applications with data classes that map directly to the schema of your Microsoft SQL Server database. Microsoft is defining a migration plan for customers that start with LINQ to SQL and require additional functionality, such as richer mapping capabilities or access to other stores, to migrate to the ADO.NET Entity Framework.
Microsoft has been banging the Entity Framework drum for a while and have been quite dismissive about LINQ to SQL, almost as soon as it was launched. But LINQ to SQL has had an interesting history, and it is that history which is responsible for both its popularity and its demise. A bit of digging into that history gives a clearer picture why the end of LINQ to SQL is inevitable.
LINQ to SQL started, it seems, as a bit of a backyard project cobbled together out of the ruins of Microsoft's failed WinFS and ObjectSpaces. Matt Warren's popular post on The Origin of LINQ to SQL has, as its first line:
LINQ to SQL, possibly Microsoft’s first ORM to actually ship in ten years of trying, was never even supposed to exist.
So how, did a product that was not supposed to exist become so popular? How come, if Entity Framework was nearly there, was LINQ to SQL even released? I believe that the answer lies with Anders Hejlsberg, "the Chief Architect of the C# programming language and also sort of the Chief Languages Strategist, if you will, for Visual Studio languages." Anders, it seems had a bee in his bonnet for building query directly into the language, and as the person responsible for C# (and the .net framework to a degree), he was in the perfect position to make that happen. It has been in his mind for a while and the introduction of generics in .net 2 was a start along the path that added lambda expressions, anonymous types, object initializers and a whole lot of other language features that finally gave us LINQ. There is a great interview with Anders on Software Engineering Radio that gives some great insight into his thinking.
Now think back to the first time you saw Visual Studio 2008 and a demo of LINQ. I recall the first demo that I saw showed LINQ to SQL and it seemed to be the killer app for .net 3.5 and Visual Studio 2008, and although there was some LINQ to Objects, it was the database access that stole the show. After all, if LINQ was going to help with the Object-Relational impedance mismatch, it had to talk to a real database. The Microsoft marketing machine needed something to rally around for the launch of Visual Studio 2008 and LINQ was the feature that they were getting everyone excited about.
At the time of the Heroes Happen Here launch, Entity Framework was simply not there - even less than SQL 2008 and HyperV (which weren't really there either). So it was natural that LINQ to SQL would be rolled in to show off how great Visual Studio 2008 is and why we should rush out and buy licences. LINQ to SQL was in a political backwater - it was developed by the
SQL Server team C# Team, not the ADO team - so officially it had no place in Microsoft's data access strategy. But Anders needed it to show off C# 3 and the marketing people liked how it looked.
LINQ to SQL enjoyed popularity from the the word go, to such an extent that Microsoft was struggling to get developers to understand that LINQ was not just about data access and that you could use LINQ on Objects, XML, DataSets, Entities (eventually) and a whole host of other technologies. It is something that they are still struggling to get people to understand, to such a degree that they have to explain that although LINQ to SQL is dead, LINQ itself is not. LINQ to SQL grew in popularity as Entity Framework struggled under the backlash of the Vote of No Confidence by the ALT.NET community - something that LINQ to SQL escaped because it was never considered an ORM nor a competitor to nHibernate anyway. LINQ to SQL is also simpler, with a smaller learning curve for developers more familiar with DataSets than ORMs. LINQ to SQL was also available at release, with Enity Framework coming in in the badly named .net 3.5 Service Pack 1 - with no thunder or fanfare.
LINQ to SQL was never going to survive - it is a 'good enough' data access framework, but is nowhere near being an ORM. And as a data access framework it only supports SQL Server - how can a single database framework be viable? LINQ to SQL has, and will continue to confuse that market in terms of Microsoft's data access strategy. Microsoft wants you to use Entity Framework, their killer ORM, a data access framework that is apparently going to solve all of our problems.
LINQ to SQL has served its purpose. It helped demonstrate LINQ's promise, at a time when dynamic languages are becoming popular. LINQ to SQL provided a good marketing platform for C# 3 and Visual Studio 2008. LINQ to SQL has been good to Microsoft, but it is time to let it go - so that Entity Framework can step up to the plate and, standing on the shoulders of LINQ to SQL, become the data access technology that Microsoft thinks we need.
However, I don't think that LINQ to SQL is going to go away quietly and people should try and understand more about what made LINQ to SQL so popular. I think that there is a large group of developers that have moved away from pure DataSets but are not interested drinking the Enity Framework or nHibernate Kool-Aid. There are developers out there, such as Jeff Atwood who took a more pragmatic approach to all aspects of building stackoverflow.com - using LINQ to SQL and ASP MVC. There are developers and even entire enterprises that have made their bed with SQL Server and don't really care if their data access framework doesn't support Oracle or MySQL. LINQ to SQL is part of the .net framework, so it is never going away - but it can never be taken out and open-sourced either.
Maybe they should just quietly give LINQ to SQL to the SQL Server team.
Update: Damien's comment sent me to his blog where he has additional clarification of what the LINQ to SQL team is up to in his post LINQ to SQL Next Steps