Is LINQ to SQL Truly Dead?

| by Jonathan Allen Follow 641 Followers on Nov 01, 2008. Estimated reading time: 5 minutes |

Back in July we reported that LINQ to SQL was transferred to the SQL Data Programmability team. This event raised a lot of concern in the developer community, who worried that work on LINQ to SQL would halt in favor of ADO.NET Entity Framework. A recent announcement by Tim Mallalieu, Program Manager of both LINQ to SQL and Entity Framework, has exacerbated those concerns.

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.

If you read this literally, it merely says that Entity Framework will get more development resources than LINQ to SQL. The problem is Microsoft has a long history of deprecating data access technology without outright saying it is no longer supported.

Before we get too far into the future of LINQ to SQL, let's take a moment to consider its past. In The Origin of LINQ to SQL, Matt Warren describes his project as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready. But that project, along with the larger WinFS project, seems to have gone down the rabbit hole never to return. Needing something, the decision was made to start the process of making LINQ to SQL a shippable product.

Meanwhile, another project was spinning up. ADO.NET Entity Framework was presenting itself as a total solution for mapping between object models and relational databases. Unlike LINQ to SQL, which was specific to SQL Server, this would have a pluggable backend that theoretically could support any database.

The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack. The Entity Framework is being criticized for two reasons.

Developers do not like it because of the complexity. There is far more a developer needs to learn to use it correctly than is needed for LINQ to SQL. Unlike Entity Framework, LINQ to SQL is best used as a simple query and update mechanism without any customization aside from basic table mappings.

Database Vendors do not like it either for an entirely different reason. Entity Framework isn't database specific and offers no way to add database specific features. This is making it hard for vendors like Oracle to get the kind of performance and functionality they need. DataDirect, a leader in high performance database adapters, won't be releasing their Oracle and Sybase drivers until early next year. And Oracle itself won't even discuss a possible release date because they can't get the performance they want without Microsoft adding additional hooks into the framework.

With so much going against it, it is no wonder that teams wanting a lightweight ORM do not see Entity Framework as a viable option. But at the same time, they are worried that LINQ to SQL is already a dead technology.

In a post titled Microsoft kills Linq to SQL, Ayende Rahien writes,

Doing something like this is spitting in the face of everyone who investment time and money in the Linq to SQL framework, only to be left hanging in the wind, with a dead end software and a costly porting process if they ever want to see new features. Linq to SQL is a decent base level OR/M, and I had had several people tell me that they are willing to accept its current deficiencies, knowing that this will be fixed in the next version. Now, there isn't going to be a next version, and that is really bad for Microsoft reputation.

A commenter on the original story named Jens wrote,

So you guys are actually admitting that Linq To SQL is a dead end? Thanks a lot. Linq To SQL has that 'it just works' attitude to it and is the underpinning of our new project. I coud never ever persuade my boss to go to Entity Framework.

John, another commenter, wants a reasonable migration path between the two and a lightweight version of Entity Framework.

A appreciate the desire to have a single 'Linq to DB' framework, but I hope the proposed Entity Framework will offer full Linq To Sql compatibility? Allowing a painless transition to people who don't need all the extra muscle of the framework. I'd rather do OR mapping myself, and use Linq To SQL as a simple way to grab the data only. EF is current a long way from what I'd need!

This sentiment is echoed by several other comments. And that's exactly what Microsoft is doing. In a follow-up post Tim Mallalieu explains,

Over the last few months we have been looking at how to carry forward LINQ to SQL and LINQ to Entities. At first glance one may assert that they are differentiated technologies and can be evolved separately. The problem is that the intersection of capabilities is already quite large and the asks from users of each technology takes the products on a rapid feature convergence path. For example, common asks for LINQ to Entities (that are being delivered with .NET 4.0) are POCO and Lazy Load. Similarly, in the LINQ to SQL side we are being asked to provide new mapping strategies and other features which the EF already has. Additionally there are common asks for new features like UDT’s and better N-Tier support for both stacks. The announcement really centers around the point that, after looking hard at this and triangulating with internal partners and customers, we decided to take the EF forward with regards to the overall convergence effort and over time provide a single solution that can address the various asks.

So there you have it; over the long run LINQ to SQL and LINQ to Entities will merge. In the mean time, development work on LINQ to SQL will not end entirely.

We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Typo in title... by Clinton Begin


Open Souce it by matt mcknight

Microsoft should just open source LINQ to SQL. If not, a simple implementation seems like a worthy option for someone to create.

You gotta be kidding me!!!! by Michael Nino

Yes. Please open source it. I have been waiting years for a good light weight ORM. Come on Bill!!! Don't leave us hanging.

Anyone recall the 90's? by fuser smith

Anyone who is surprised by this apparently wasn't working as an MS developer back in the 90's. They came out with a new database API (it seemed) every 6 months. These days I don't join MS on the bleeding edge.

Re: You gotta be kidding me!!!! by asd dsa

But you saw Subsonic 2.1 (Supports Sql Server, Oracle and in the future PostGreSQL). I think it will be the change of Linq and Ado.Net Entity. In fact is Open Source

Ma avete visto SubSonic(Supporta Sql Server,Oracle in futuro anche PostGreSQL). Penso che sarà il sostuituto di Linq e di Ado.Net Entity. In fatti è Open Source

Exasperated by Marcel Parnas

Sorry, but this is the second time I've recently seen the word "exasperate" used this way, and it's starting to, well, exasperate me. So I thought I would do whatever I could to, well, not exacerbate the problem. Below is what Merriam-Webster has to say about these two:

1 a: to excite the anger of : enrage b: to cause irritation or annoyance to
2 obsolete : to make more grievous : aggravate

: to make more violent, bitter, or severe <the proposed shutdown…would exacerbate unemployment problems — Science>


Re: Exasperated by Scott Wills

Do they (MS) appreciate how completely foolish this makes anyone appear who might have advocated any sort of early adoption? My detractors in the old-school have just scored big in their fight to win me back. I and others like me, who embrace change, value innovation, and labor hard to advance our goals do not forget such failures.


And no one has mentioned performance by Marcelo Lopez

No one's discussing that to get any semblance of performance, one is practically relegated to restoring to (pseudo-TSQL) Entity SQL, which quite frankly negates the whole of moving from most developer's perspective to EF from Linq. To finally move away from the g_d forsaken quagmire that is TSQL ( and syntaxes like it ).

Before the TSQL faithful come bearing pitchforks and torches at my gates, hear me out. T-SQL, PL-SQL, and their ilk are wonderful for wringing the most out of our database engines, but they're horrid to debug in many cases( anyone debugging a trigger has to be honest with themselves about that statement ), and as a "language" woefully restrictive compared to the expressiveness of most languages in great use today. Sure, SQL SERVER 2005 and above allow embedding CLR stored procedures, but that's not the panacea everyone's hoped for, and it is yet again, tied to a singular technology tree. Linq to SQL displayed true hope of finding a middle ground between the flexibility of ORM mapping that EF says it promises ( one would not need to resort to Entity SQL if all of EF's promises were up to snuff ) and speed of direct ADO.NET/TSQL offer instead.

I could make a longer point, but if we're honest with ourselves, we have to come to the conclusion that this shift in responsibility for the future of Linq to SQL, not only does NOT bode well, but truly is a shame. I've seen technology after technology deprecated ( Win16, Thunking, COM, DCOM, .NET Remoting ) by Microsoft over the past 20+ years I've worked in this business. Some technologies too soon ( .NET Remoting ), some not quickly enough ( DCOM, Thunking ). Honestly, I have a hard time seeing any great adoption of EF as long as the tools aren't as mature as other ORM alternatives. Sure, they don't bear the "Seal of Approval" from Microsoft, not per se anyway, but having that seal doesn't seem to bother Microsoft enough to not have the proper resources devoted to truly making something special out of Linq to SQL.

Have a look at Entity SQL, and then ask yourself, "Is this really the advancement it's cracked up to be ?". I think not. If someone can truly make a strongly convincing argument for EF/Entity SQL being a win-win, I've yet to hear it.

Re: Exasperated by why must I register to comment...

Do they (MS) appreciate how completely foolish this makes anyone appear who might have advocated any sort of early adoption? My detractors in the old-school have just scored big in their fight to win me back. I and others like me, who embrace change, value innovation, and labor hard to advance our goals do not forget such failures.

But being an early adopter of Microsoft technologies *is* foolish, for this very reason. It took me a several years to figure that out, but here we are. If you want to be an early adopter, be wise and adopt an open source project, where at least you can bring the project forward yourself in the unlikely event that the community abandons it.

Some of my colleagues adopted Linq2Sql for their project at about the same time I adopted NHibernate for my project. Guess who's having a better Monday?? :)

Re: Typo in title... by Carter Mitchell

Worse: "...has exasperated those concerns." I just cringed. While the author may be exasperated by the situation, concerns would not be. His concerns may, however, be exacerbated.

Taking a big picture look at Entity Oriented Data Access Matters by Kingsley Idehen

I would encourage readers and commentators associated with this post to look at the my post about Linq2Rdf [1]. We are moving data access focus away from the logical up to the conceptual level, but in doing so, we must understand that getting to SQL data from LINQ isn't going to be solely about LINQ-SQL which introduces major peformance challenges.

We see directly binding to Entities via RDF Linked Data as a viable open solution for high-performance, scalable, and platform indepenent Entity oriented Data Access.



Kingsley Idehen
OpenLink Software

No early adoptions.... by .Net developer

I have learned that working with MS requires you not to be an early adopter. Even their products have improoved their quality (less errors) there are still bugs and unexpected trends to come (like this one) with new versions.
I always think that MS is always running to get new releases out too fast, just look at ".Net", we are expecting new versions every 18 months (in the latest ones) and that's too much!

Re: No early adoptions.... by Katie Quinn

L2Q is great. I love working with it. Have not found it to be slow as someone mentioned above. I have done three projects with it and love how it integrates with VS08. What a shame to have MS make this decision! I have not tried L2E. Am very satisfied with L2Q!!!!!!

Microsoft Access LINQ Provider by asava samuel

Jonathan Allen

Here is a LINQ Provider for MS Access:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

14 Discuss