News

Is LINQ to SQL Dead?

Developers are angered by Microsoft's shift to Entity Framework.

• By Jeffrey Schwartz
• 01/01/2009

Chuck Hanson started feeling uneasy last month when he heard rumblings that one of Microsoft's year-old data-access protocols, LINQ to SQL, might be sidelined in favor of an even newer technology -- ADO.NET Entity Framework (EF).

Hanson, a software architect for the Nebraska Department of Roads 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 says, admitting he's nervous and seeking advice. While Hanson may be uncertain what to do, so far he hasn't 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, which 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," says Howard Richards, a principal with U.K.-based development firm Conficient, who says 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 DOA 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 2008 in October. It was then that Tim Mallalieu, the program manager for both LINQ to SQL and EF, wrote a blog posting that created the debate that raged into the holiday season.

"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, says: "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 says LINQ to SQL was handed off 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 explains.

He's seen the speculation about the future of LINQ to SQL and says communication from the data team about this issue could be better: "I can assure you, it's not dead," says Heljsberg. "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," says Microsoft Regional Director Stephen Forte, who is 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 says, 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, says 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 says.

"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 adds.

Critics complain the decision was a political battle between two development groups within Microsoft. Mallalieu says 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 says 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 says, including a large bank and an insurance company.

Apple to Oranges
Nevertheless, those who 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," says 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 adds: "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."

	"If you put LINQ to SQL under Entity Framework, it's dead."
Stephen Forte, Chief Strategy Officer, Telerik Inc.

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 says.

"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," he adds.

But Roger Jennings -- principal of Oakland, Calif.-based Oakleaf Systems, who authored a cover story last month in RDN's sister publication Visual Studio Magazine covering O/RM using LINQ to SQL ("Speed O/R Mapping with LINQ to SQL," December 2008) -- says that's a big if. Jennings argues Microsoft appears to be backing off on features that were presumed to be slated for EF version 2. One example: In a blog posting last 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 says. "Basically what they're doing is back-pedaling on their original commitment."

Jennings also points 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 says. Jennings adds that it was presumed that would make the EF version 2 release.

"That's called, it's fallen off the list," Jennings says. "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, says developers shouldn't draw conclusions based on what was posted to her blog. Flasko says 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 says: "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," says 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 says.

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."

LINQ to SQL won't be a huge focus in .NET Framework 4.0, he says, 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," Mallalieu says.

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, asserts Forte.

"If Microsoft is serious about Entity Framework being the preferred data-access solution in .NET 4.0," he says, "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.

Migrating from LINQ to SQL to the Entity Framework LINQ to SQL Next Steps Entity Framework Design Stephen Forte: LINQ to SQL Is Dead Roger Jennings' Blog