Welcome to EMC Consulting Blogs Sign in | Join | Help

Simon Munro

Move over LINQ to SQL - you have served your purpose

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

Simon Munro

Published Sunday, November 02, 2008 10:38 PM by simon.munro
Filed under: , , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Anthony.Steele said:

Having played with LINQ to SQL, his is a bit disappointing, But I am running up against the limitations in my test code - The objects generated by LINQ to SQL may be Plain Old objects, but they reside in the data layer, unless you put in a lot of effort. I found saving deeply nested hierarchical data to be a manual and labour intensive process. If I can take my LINQ to SQL code and use it on a later product that has all the features (and some new ones) and not much extra overhead, then I'd be happy, even if the later product is called "LINQ to entities".

The interesting question is: if you were starting a project tomorrow on the current Microsoft technologies, what would you use for the data layer? I suspect that since LINQ to SQL's successor is not here yet, the answer may be the mature option - NHibernate.

November 4, 2008 12:29 PM

simon.evans said:

The Microsoft product is there... its the ADO.NET Entity Framework delivered in .NET 3.5 SP 1, which includes LINQ to Entities

With EF out there is no point in LINQ to SQL anymore. The entity framework does everything that LINQ to SQL does, and much more besides.

As for a comparison to NHibernate.. thats an interesting question, and very hard to answer. EF has got a bad press amongst the ALT.NET community, but I'm not sure how much of this is down to real experience with the framework. I'm using it on a project at the moment and I'm pretty happy with it. Some things could and should be better, but some things are very good indeed (like the designer and its compilation error handling).

November 4, 2008 12:58 PM

simon.munro said:


If I were to start a brand new project using the current stack I would go for EF or nHibernate.  My bias is toward EF because I am not much on an nHibernate guru and I like LINQ (to Entities).  Interstingly, this week Ayende posted on his blog a request for sponsors for LINQ to nHibernate http://ayende.com/Blog/archive/2008/11/01/developing-linq-to-nhibernate.aspx .  Maybe nHibernate are thinking of the things that attracted people to LINQ to SQL in the first placce.

November 4, 2008 3:09 PM

Anthony.Steele said:

Simon (Evans),

Indeed, EF is here now. The bad press that it got (http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/ ) seem to indicate that EF lacks a couple of features from LINQ to SQL  - particularlly lazy loading and persistence ignorance. Perhaps these will come in Version 2.

November 5, 2008 1:58 PM

simon.evans said:

Hi Anthony

Funny you mention these points around lazy loading and persistance ignorance.

Both points are going to be addressed in v2 of the Entity Framework, but I think its worth keeping the lack of support for these feature in EF:

1. Persistance Ignorance is not really supported in LINQ to SQL more than it is in EF. Most people view this as meaning a pure POCO entity, which neither LINQ to SQL or EF currently supports. EF entities inherit EntityObject, and both EF and LINQ to SQL raise events and implement INotifyPropertyChanged to support 2 way binding in WPF. The bad bit is not that EF and LINQ to SQL do this... more that you cannot use either with pure POCO DTO entities.

2. Yes its not there at the moment.. is that a "bad" thing, or just a feature not supported yet? Personally, I think lazy loading is a feature that requires careful use, because overuse can just involve more database round trips for smaller sets of data... which can be less efficient.

All of this said.. EF does do these things very very nicely:

1. Excellent build support; if it isn't mapped 100%, it won't build

2. It works with other databases (I'm currently using it with Oracle)

3. It properly seperates the structural model from the conceptual entity model.

4. It maps many to many relationships properly.

5. Its all strongly typed

You pay your money....

November 6, 2008 5:42 PM

Damien Guard said:

Nice article and comments, just a few points:

LINQ to SQL was developed by the C# team not the SQL Server team.

EF doesn't do everything LINQ to SQL does yet but we're working on bridging that gap.

LINQ to SQL supporting INotifyPropertyChanged is part of the data binding story and isn't evidence of a lack of persistence ignorance - two totally different things.


November 7, 2008 8:23 PM

simon.munro said:

Thanks for popping by Damien, I am sure it has been a busy couple of weeks for the Data Programmability team.  Thanks for the clarification of the original team who developed LINQ to SQL - I thought that was the case, it makes sense after all, but I couldn't find a reliable reference.

November 9, 2008 8:33 AM

Mike said:

To me its about speed, really.  From my testing, the most simple queries are more than twice as fast on L2S than EF.  Even in following MS's guidelines on speeding up EF pre-view generation only helps cut out a few hundred milliseconds.  But I will say this, the one thing I like better with EF is the way it handles string comparisons to NULL.

December 11, 2008 2:16 PM

Tim said:


Read the metrics on LINQ. Its really not for enterprise level applications.

Good for modeling, but people tend to get lazy and start in one direction and never stop.

Stored Proc's + DataReaders; pretty hard to beat those in raw speed.

Forget EF and L2S. EF is a sound premise, but is completely verbose and un-maintainable (we typically call this "wizard based programming"). L2S will always have an overhead over SQL/Stored Procs. Neither are a good solution.

June 24, 2009 6:29 AM

Raju said:

I try to use InotifypropertyChange but problem is that i only find on net that what is InotifiyProperty change but i never find that who it is use using linq to sql classes in complete way I try to use my Student class which have MyImag dbtype varbinary and firstname And date also but when i try to use like

pulics class student:InotifypropertyChange{} then error is occur which say that missing partial midifier please tell me who to use it please

January 21, 2012 9:25 PM

Leave a Comment

Powered by Community Server (Personal Edition), by Telligent Systems