Is LINQ to SQL Truly Dead?
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.
Open Souce it
You gotta be kidding me!!!!
Anyone recall the 90's?
Re: You gotta be kidding me!!!!
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
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>
And no one has mentioned performance
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.
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...
Taking a big picture look at Entity Oriented Data Access Matters
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.
No early adoptions....
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....
Microsoft Access LINQ Provider
Here is a LINQ Provider for MS Access:
Tom Gilb & Kai Gilb Jan 26, 2015