Is LINQ to SQL Dead?
Chuck Hanson started feeling uneasy earlier this 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
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."
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
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
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,"
"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,"
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
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,
"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