Microsoft Says LINQ to SQL Not Dead
Microsoft's controversial decision to position the ADO.NET Entity Framework
has generated a lot of backlash among developers who made early bets on LINQ
to SQL, which the company had released with Visual Studio 2008 and the .NET
Framework 3.5. See my complete story here. I received quite a few e-mails from
developers partial to LINQ To SQL and suffice to say, many are felt left at
the alter.
While some I spoke with are coming to terms with it, others are angry. "I
feel stabbed in the back by this but I'm not moving," said Howard
Richards a principal with UK-development firm Conficient, who says he invested
a year with LINQ to SQL and now feels blind sided. "What annoys me most
is Microsoft's cavalier attitude to its developers in this regard. It took
me six months to port my application from a 'homebrew' data layer
to LINQ to SQL."
Yesterday I spoke with Tim Mallalieu, the program manager for both LINQ to
SQL and the Entity Framework, who says Microsoft anticipated the backlash but
said both data access interfaces will be better off for this move. For those
who don't think the Entity Framework is a suitable replacement, Mallalieu
said stay tuned.
"There's some pretty nifty stuff we're doing in the beta 2 time frame that
we are not speaking about as yet, I think it will give you a better experience
and will reduce the anxiety that people have around the Entity Framework," Mallalieu
said. "In terms of capabilities, I think will make the overall integrated experience
of ASP.NET, Dynamic Data, MVC and these other things easier, we did a little
bit of triaging and feedback, there is some valid feedback around complexity
in the Entity Framework and we are doing things to address that. "
What follows is an edited transcript of our conversation.
How widely deployed is LINQ to SQL today?
All indications were that it was like any nascent technology, there was a lot
of interest from an exploratory perspective but there wasn't a lot of significant
-- in terms of the entire .NET eco system -- pushes going into production. There
were a bunch of people kicking the tires, there were some pretty interesting
things going into production. We are still trying to get a better way in general
in the company to gauge technology adoption, but today, I can't give you a definitive
number.
Were you surprised at the reaction?
We knew that this wasn't going to be a popular decision just because LINQ
to SQL is a really interesting technology. It's very nice. The problem
is though, when you make a decision like this, you can either say we don't
want to [tick] off the community, which means that you get a bunch of people
just betting on the technology to a level which will not meet with their expectations
of future innovation, release after release. Or you could actually take the
hit and get the tomatoes thrown at you early in an effort to do right by the
customers. So what we were trying to do, maybe we could have done it better,
is to do right by the customer and set expectations early for where we were
going.
For those who say this was a political decision and not a technology decision,
is that an unfair characterization?
There were a number of political aspects to why we released two technologies
to begin with but in the grand scheme, what we were trying to do with the .NET
Framework right now was to reduce the amount of overlapping technologies that
we keep on dumping out as opposed to increasing the number. We convinced ourselves
internally that it was okay to release LINQ to SQL and Entity Framework because
there was clear differentiation between the two, and the markets we were going
to go after were different.
The reality is if you go look at what people are asking for, the rate of convergence
from a feature set perspective of the two stacks was two releases away from
convergence. So you look at that and say we could spin up two teams of equal
size to go do this work, and within two releases you are talking about two stacks
that look almost exactly alike, or you can say one of these technologies has
already been identified as a strategic piece of a bigger data platform vision.
From a shared investment perspective and technology roadmap perspective, it
seemed like the right thing to do. The problem is because there were some initial
conflicts that people have rumbled about from the history of the two technologies,
it's hard to see that there was actually an attempt to make pragmatic decisions
that were not covered by any political intentions.
If you had two technologies that were covering the ORM space, and one was pretty
nifty, was very fast, lightweight but people were saying they wanted things
like a provider model people were saying they wanted things like many-to-many
relationships, people were saying they wanted the more complex inheritance mapping
but you said there's another technology that has already done that stuff and
we think is the foundation for a broader data platform vision, would you build
those features into the other technology, or would you say, "it sounds like
what people are saying they want all of those scenarios but they want the added
simplicity"? So from a roadmap perspective it just did not make sense to duplicate
efforts from in two code basis.
What can you say to those who feel stabbed in the back or duped by this
change in strategy?
There are few things I can say that will actually make it better. But as soon
as we came to the decision, we felt the best thing to do was to come up early
and tell people so they understood what the situation was as opposed to playing
them alone. I think it would have been much more painful to wait two years to
be talking about why we weren't investing at that level in the technology.
We expect that people will continue to develop with LINQ to SQL, it's a
great technology, we are going to provide with the patterns and practices group
in Microsoft for how to design LINQ to SQL so if you are happy with them, you
just stay with it. If you at some point after using LINQ to SQL want to move
to the Entity Framework, hopefully if you follow the guidance that we will give,
it won't be as hard to move. You don't just go down a path where you've
fallen off a cliff. But beyond that, it's not the kind of message that
I can sit here and say something to you that would be a panacea for the community.
In hindsight do you regret releasing LINQ to SQL and not just waiting for
the Entity Framework to be ready?
I think LINQ to SQL is a very important technology, 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 it's 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.
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.
Do you see there being new LINQ to SQL features?
We see there being new LINQ to SQL features, I don't know if there will be substantial
new LINQ to SQL features in .NET 4.0. After .NET 4.0 we have every intention
of doing feature work in LINQ to SQL. We are also doing a bunch of bug fixing,
servicing, and that kind of work. LINQ to SQL was developed by the C# team,
when Visual Studio 2008 .NET Framework 3.5 shipped, there was a transition of
the technology into our team. The problem that we had was the transition didn't
come with people, it came with just the technology, and we immediately were
tying to do work for .NET Framework 3.5 SP1, we wanted to add support for the
new SQL Server date types into LINQ to SQL so we focused tactically on SP1 just
on getting some of the features and design change requests that the C# team
said needed to be in to get the service pack done. That meant that when we shipped
the technology we had to officially take ownership of it, which meant we had
to get the technology on boarded. We are different teams and have slightly different
focuses, and we had to get new people ramped up on the technology, given that
.NET Framework 3.5 SP1, released halfway through our development cycle for .NET
Framework 4.0, and given the adoption work I just described, it was really hard
for us to do any significant work in .NET 4.0, but we intend to do feature work
in the future.
Posted by Jeffrey Schwartz on 12/18/2008