News

Is LINQ to SQL Dead?

• By Jeffrey Schwartz
• 12/18/2008

Hanson, a software architect for the Nebraska Department of Roads who's responsible for overseeing the transition from Java-based development to .NET, has suddenly found himself wondering how to proceed.

"I'm not sure how this is going to play out," Hanson said, admitting he is nervous and seeking advice. But while Hanson may be uncertain about what to do, so far he has not invested in either data-access technology.

Hanson is reckoning with the realization that Microsoft's LINQ to SQL data-access protocol may be getting short shrift in Redmond these days as the company continues to shore up its focus on its object/relational mapping (O/RM) tool, EF. EF finally appeared in .NET 3.5 Service Pack 1 (SP1) after getting cut from beta 1 of the framework days after it shipped. EF version 2 is expected to be part of Visual Studio 2010 and .NET 4.0 Framework.

Unlike Hanson, other developers have spent the past year building applications using LINQ to SQL. A recent survey of 378 developers who have downloaded Connect for ADO.NET by Bedford, Mass.-based database-connector supplier DataDirect Technologies suggests 8.5 percent of .NET apps in production use LINQ to SQL as their primary data-access method. Many developers are feeling betrayed by Microsoft's decision to discontinue the building of any major new features in LINQ to SQL, released late last summer as part of Visual Studio 2008 SP1.

"I feel stabbed in the back by this, but I'm not moving," said Howard Richards, a principal with U.K. development firm Conficient, who added that he invested a year with LINQ to SQL and now feels blindsided. "What annoys me most is Microsoft's cavalier attitude toward its developers in this regard. It took me six months to port my application from a 'homebrew' data layer to LINQ to SQL."

Short Lived?
Some would argue LINQ to SQL was dead on arrival when it arrived in .NET 3.5 Framework just over a year ago, but Microsoft made that all but official during its Professional Developers Conference in October. It was then that Tim Mallalieu, the program manager for both LINQ to SQL and EF, wrote a blog post that continues to spark discussion.

"We're making significant investments in Entity Framework such that, as of .NET 4.0, Entity Framework will be our recommended data-access solution for LINQ to relational scenarios," Mallalieu wrote. Days later he issued an update saying that Microsoft "will continue to make some investments in LINQ to SQL based on customer feedback."

Microsoft Technical Fellow Anders Heljsberg, head of LINQ and C# development, said, "The LINQ to SQL project was an interesting project because it was built by the C# team, yet it clearly is in the data domain. We built it because we needed something real to validate LINQ, and we strongly felt that LINQ would be nothing without a strong OR mapper to support it, because that's the majority of at least the initial use that we've seen in that space."

Heljsberg said LINQ to SQL was handed to the ADO.NET team, which was in the process of building EF. "Right now we have the two of them sitting out there," he explained.

He has seen the speculation about the future of LINQ to SQL and said communication from the data team about this issue could be better: "I can assure you, it's not dead," Heljsberg said. "We've invested a lot in it and customers have invested a lot in it, and it's not just going to go away."

Still, many saw Mallalieu's words as the death knell for LINQ to SQL. "It's dead as a door knob," said Microsoft Regional Director Stephen Forte, chief strategy officer at Telerik Inc. "As long as LINQ to SQL lives under Entity Framework, it's dead. I don't care what anyone says -- even if Bill Gates comes out of retirement and says LINQ to SQL has a healthy future."

Two Teams Too Many
Mallalieu espouses a different view. "I think LINQ to SQL is a very important technology," he said, noting that for Microsoft it makes little sense to devote two separate development teams to technologies that would ultimately offer similar capabilities. LINQ to SQL, he and others maintain, is a lightweight data-access technology and would lose its appeal if Microsoft looked to bolster it.

As a result, Microsoft has been looking for ways to support both LINQ to SQL and LINQ to Entities, which lets developers build queries against EF.

Microsoft had little choice but to consolidate the two development efforts, said Gartner Inc. analyst Mark Driver. "Microsoft has always had a history of coming up with multiple variations of database access among different teams, and they realize they can't do that if they're really going to target the enterprise large-scale development -- they need something consistent," Driver said.

"They have what I believe is a good plan around Entity Data Model, this abstracted high-level set of data services that can be targeted at a variety of products and solutions and still maintain consistency and consolidation," he added.

Critics complain the decision was a political battle between two development groups within Microsoft. Mallalieu said he regrets the controversy that has erupted but believes it was better to move now than to wait two years after far more investments were made in both technologies. Mallalieu doesn't deny the infighting but he believes the decision was in the best interest of advancing data-access technology in .NET Framework moving forward.

Mallalieu also said most people who have used LINQ to SQL, while vocal, are primarily developers that have been prototyping and building small apps. Several large enterprises are starting to deploy production systems using the Entity Framework, he said, including a large bank and an insurance company.

Apples to Oranges
Nevertheless, those that have spent the past year working with LINQ to SQL believe Microsoft is pushing them to an alternate data-access technology that may lack some of the functionality currently available.

ADO.NET programmer Aaron Smith was always frustrated with the concurrency issue with data sets and was quick to start using LINQ to SQL upon its release.

"We had to write our own update procedure for ADO.NET in order to do that [and] with LINQ to SQL it does it for you, and that's one of the biggest things that the Entity Framework doesn't do very well," said Smith, an IT manager at R.C. Systems Inc., a Mount Clemens, Mich.-based developer of recreational-management software for local municipalities.

Ditto with deferred loading, Smith added: "Whereas with LINQ to SQL, if you do a query and you've got child tables, it will automatically populate those child tables as you iterate through the list. The Entity Framework doesn't do that. You have to go out and load those child tables yourself, and that's a whole lot of work that you shouldn't have to do."

Not Going Away
Questions about whether EF will be able to handle some of the nuances of LINQ to SQL are leading Smith to stick with the technology, at least for now, especially considering it will remain within the framework.

"With the way that LINQ to SQL is currently, we don't have any issues with it. We'd like to see a few new features, but if they're not going to add anything to it, it wouldn't be a hindrance to us because it works as is," Smith said.

He added, "If the next version of the Entity Framework has everything we need and it works very well and the performance is comparable to LINQ to SQL, we'll probably end up using both and just start migrating to the Entity Framework simply because that's going to be their recommended solution."

But Roger Jennings, principal of Oakland, Calif.-based Oakleaf Systems (and author of a cover story this month in RDN's sister publication Visual Studio Magazine covering O/RM using LINQ to SQL) said that's a big "if." Jennings argued that Microsoft appears to be backing off on features that were presumed to be slated for EF version 2. One example: In a blog posting earlier this month, Microsoft explained how developers should migrate stored procedures developed with LINQ to SQL to EF using Visual Studio 10.

"What they're saying now is support for stored procedures might be implemented in EF version 2, instead of will be," Jennings said. "Basically what they're doing is back-pedaling on their original commitment."

Jennings also pointed to the LINQ to SQL Designer, which allows developers to map stored procedures that return scalars. While acknowledging that such automatic code-generation of methods is missing, Microsoft is now saying "this is something that's being strongly considered for the next release of Entity Framework," he said. Jennings added that it was presumed that would make the EF version 2 release.

"That's called, it's fallen off the list," Jennings said. "The upshot is it appears the team is paring their list of what they're going to implement in EF version 2 from what the original plan was."

Elisa Flasko, a program manager in Microsoft's Data Programmability group, said developers shouldn't draw conclusions based on what was posted to her blog. Flasko said the contributions come from various developers and that Jennings and others shouldn't take the words too literally. Plans around stored procedures haven't really changed, she said: "We've actually done a ton of the work already and it's actually already in the internal bits."

Industry on Board
Microsoft's moves are already steering momentum toward EF. Both Oracle Corp. and IBM Corp. are planning EF connectors to their respective databases. DataDirect is focusing on the EF and has no plans for LINQ to SQL.

"I don't think the Entity Framework is necessarily perfect, but I think it's going to change the outlook of data access in .NET," said Jonathan Bruce, ADO.NET technologies program manager at DataDirect, which is a subsidiary of Progress Software Corp. "I think LINQ to SQL will likely find its niche in small, in-house proof-of-concept type projects because it's easy to get going -- it has a very lightweight data model."

While Telerik's Forte is concerned Microsoft's guidance on how to reconcile its various data-access protocols won't be adequate for some time, he believes the shakeout will be organic. "Unfortunately, the thing that makes Microsoft great and innovative -- its sometimes disparate teams -- leads to the confusion in the marketplace," he said.

Microsoft's Mallalieu insists LINQ to SQL has a strong future. "It's unfortunate how this is ending up for customers, but I think given where we were from a product perspective and a technology perspective that LINQ to SQL is really important, and I think in its current existence and with the kinds of work that we expect to do with it moving forward, it's still going to have a good following," he said.

LINQ to SQL won't be a huge focus in .NET Framework 4.0, he said, though it will be tweaked as needed.

"It's just not going to be the be-all-and-end-all enterprise O/RM that has every little knob and bell and whistle. Quite frankly, if you were to add every little knob and bell and whistle, you'd wake up and find all the elegance and simplicity of LINQ to SQL would be gone."

LINQ to SQL developers will be ready to move to EF when it's a superset of the lighter-weight technology and Microsoft releases the migration wizards, Forte asserted.

"If Microsoft is serious about Entity Framework being the preferred data-access solution in .NET 4.0," he said, "they'll have to do a few things: Make EF 2.0 rock-solid. Explain to us why EF is needed. What is the problem that Entity Framework is solving? Why is Entity Framework a better solution to this problem?"

How this will all turn out remains to be seen. Meanwhile, Hanson, the data architect at the Nebraska Department of Roads, is scouting out advice from various consultants.