There has been a variety of responses to the post on L2S futures in the last couple of days.
Let me start by saying sorry for the radio silence since the post but, as Elisa mentioned, we posted it while at PDC and were focusing on the interactions there over the last couple of days.
There are a couple specific points that I would like to clarify:
Is LINQ dead?
No… heck no…
There is a big difference between LINQ to SQL and LINQ.
LINQ is Language Integrated Query, today we ship the following sources over which one can execute a LINQ query:
- DataSet : LINQ to DataSet
- XML: LINQ to XML
- In Memory Objects: LINQ to Objects
- ADO.NET Data Services (Astoria) Client: LINQ to Data Services
- LINQ to Relational Databases:
- LINQ to SQL – the technology we were discussing in the original post
- Entity Framework (LINQ to Entities)
There are many other people in the company and broader community working on LINQ solutions to other data sources. We are also excited to see LINQ being applied to many cool new problems beyond the typical data access scenario.
The discussion in the post was about the difference in investment level that we will have going forward regarding LINQ to SQL and the Entity Framework. LINQ itself, is a fundamental technology that we will continue to bet heavily on.
So what exactly is the announcement about?
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.
Is LINQ to SQL Dead?
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. As mentioned, we have been working on this decision for the last few months. When we made the decision, we felt that it was important to immediately to let the community know. We knew that being open about this would result in a lot of feedback from the community, but it was important to be transparent about what we are doing as early as possible. We want to get this information out to developers so that you know where we’re headed and can factor that in when you’re deciding how to build future applications on .NET. We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.
Tim Mallalieu
Program Manager, LINQ to SQL and LINQ to Entities
PingBack from http://mstechnews.info/2008/10/clarifying-the-message-on-l2s-futures/
I think this makes sense (my impression of both to date is that each has good features that the other lacks, so convergence would be very attractive), but to do you mind if I get started right now with a couple of items on my list of things to be added to LINQ To Entities?
1) Performance improvements: from what I’ve seen to date L2S significantly outperforms L2E. Some tuning would be nifty, thanks.
2) LINQ To SQL is very good at inferring appropriate singular and plural names from table names, whereas LINQ To Entities doesn’t try. This is a very useful feature, please steal it.
Since POCO and Lazy Load are already being worked on I’ll just note that if they weren’t, they’d be very high on my list.
So, ‘is linq to sql dead?’
The answer is: ‘yes, … heck yes’, otherwise it would have been ‘no…. heck no’. If you want clarity and clear communications, just be clear and not come with a long winded story which practically says the same thing as your last post.
L2E is the better bet over L2S. Now if it were only easier to work with stored procedures in L2E, you’d have a real winner. Of all the CRUD operations I’d like to perform using stored procedures within L2E the Delete portion is way to complicated and paved with far too many pot holes (1:n, m:m, etc.). Remember the KISS principle as you move forward with L2E and the use of stored procedures. A better L2E wizard that generates a proper set of stored procedures would be a nice start.
Negli ultimi giorni la notizia sono rimbalzate. Forse troppo. Ad una prima lettura non mi era sembrato
Hi,
I’m sorry, but I (and probably many others) am not able to understand this sentence
"So what exactly is the announcement about?
… 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."
Imo it has only following explanation: we will work on EF and maybe sometimes in the future it will have some unspecified features from L2S. No dates, no features,…
Also I’ve seen different requests for features in LINQ but following was not between them "Similarly, in the LINQ to SQL side we are being asked to provide new mapping strategies and other features which the EF already has. "
Best regards
Milan
I’ve read all the comments to the aforementioned post. Nobody was suggesting that LINQ was dying, it was very clear that LINQ to SQL was begin killed. Nothing irritates us more than being mislead and when we speak up you guys talk to us like we’re morons. If you really want to be open then talk to us without the marketing BS and then claim that we don’t get it. You guys really suck! How’s that for transparency?
If you’re not going to work on it anymore, are you at least going to release it to the community so that we can continue working on it?
To make a long story short: the ADO.NET team is now responsible of ADO.NET Entity Framework (including
To make a long story short: the ADO.NET team is now responsible of ADO.NET Entity Framework (including
I’d have to agree with what Kevin said above. When my company evaluated both L2S and the EF, we found that L2S generated more optimized SQL queries than L2E in the scenarios we tested (especially involving multiple joins). Making sure the generated SQL is on par with L2S performance-wise could alleviate a major concern for us.
The other main area where L2S wins right now is ease of use. Lazy loading will obviously help here. But little details like inferring appropriate singular and plural names from table names can really make a big difference in how much friction the framework creates. For my scenarios L2S often "just works", and it has a nice lightweight feel to it. If you can give that same sense to EF, but keep the extra power under the surface when you need it, I think many people would choose the EF in a heartbeat.
We do appreciate the transparency, and would love to see the best of both L2S and EF merged into a single uber-framework if done right. Hopefully the combined entity (no pun intended) doesn’t end up being too complicated or cumbersome. I think that’s what a lot of L2S users are afraid of.
ef is an improved version of l2s, right? if we can do all with ef, why we still need l2s? I originally use l2s, but later I replaced it with ef, without do too much work, only a few functions. and since ADO.net ds is based on ef, why not we just use ef on server side and ds in client. after all, there seems no advantages of l2s over ef.
off-the-topic:
when will oracle provider for EF come out?? we are longing for it over 1 year~~~
Unfortunately, being transparent requires more than simply stating that you want to be transparent. If you want to make an announcement, then make an announcement! All that was in your prior post was some vague marketing-eese; big surprise that people decided to draw their own conclusions, when that was the only choice you left them.
As to the actual "announcement"…what you are saying is that LINQ to SQL is dead. If you were actually listening to "customer feedback", you would be focusing on LINQ to SQL instead of the Entity Framework, given that the former has enjoyed a FAR better reception in the community than the later.
So the truth is, you are going ahead with your own plans, regardless of what anyone else thinks. You certainly have that right; its your product and your money, and you can do whatever you want. I just wish you would come out and say that, instead of beating around the bush and trying to sell this as what the community wants, when clearly it is not.
Hi,
if you look at Scott Hanselman’s "Survey RESULTS: What .NET Framework features do you use?" – you will see that LINQ to SQL is used by 34%, EF by 13%. DO you really plan to throw away those 34%? (I’ve some experience with one MS depreciated project – and now fixing bugs anymore,… The real truth is that when there is nobody assigned to work for the whole time (and when are no money in the budget for it), the future is clear – nothing).
And, please, can you try to REPLY to all those questions which arose in this and previous blogs? You ask for "We also want to get your feedback", but of course, no response from you… never…
Best regards,
Milan
LINQ to SQL had BETTER continue to exist and be developed. Microsoft cannot promote a new technology one year and just dump it the next, and move on because they are working on something better.
I’ve just spent six months redesigning our line-of-business application to use LINQ to SQL instead of our own homebrew ORM. That represents a lot of time and effort and money.
While moving to LINQ to Entities would be less painful, who is to say LINQ to Entities is going to be here next year when the new ‘flavour of the year’ comes along?
Get your act together Microsoft – developers make big bets on your technologies and WE NEED TO RELY ON WHAT YOU SAY
Well, this is sad, but, this is the chance for third parties to put on the market L2S like OR/Ms that don’t have the overhead of L2E …
I really love Linq to SQL, it’s lightweight, it’s fast, it doesn’t have the runtime overhead of EF…. it’s fast, it’s got wonderful C# to sql translation where EF throws monster queries that bring the query optimizer to its knees, it’s fast, it is more flexible than EF regarding queries and it is fast.
L2S has a good place on the market where lightweight solutions are needed, and after all, you don’t always need an constrained entity model to work with data, objects ‘are’ data.
Hey Tim, keep ’em coming! You can’t make this stuff up!
p.s. I believe it is exciting that you have innovated the verb ‘asks’ and leveraged it as a noun. This truly sets the bar for bringing forward future value propositions regarding the use of English words.
There is a lot of comment around recent pronouncements from the ADO.NET team that their future strategy
There is a lot of comment around recent pronouncements from the ADO.NET team that their future strategy
Thanks for the clarification… It’s pretty clear not that we are getting screwed. We evaluated Linq2Sql and we love it. We even started rewriting existing code to take advantage of it, since it does everything we need it to do in a way we need it to do it. When ADO.Net EF came out, we started to evaluate it and when it was immediately clear that it was not only incomplete, but also a performance issue, we decided to not adopt it and stick with something that works and works well, Linq2Sql. Now we are hearing that we will be eventually forced to use EF. Time to drop Microsoft’s ORM solutions in favor of a 3rd party…
DevExpress’s XPO is a clear winner for us. Sorry, Microsoft, but you dropped the ball by letting the ADO.Net team take over Linq2Sql.
…and the "asks" from users…????
Next time, could you please speak English?
Tim, L2S is obviously dead and you should just say as such. Please stop with the unproffesional rhetoric and admit the FACT that you have stuck it to the many of us that made commitments to L2S.
After convicing my client(s) that LINQ to SQL is a great way to go, one of my clients sends me a link to this blog. I have lost credibility and look like an idiot.
Thanks for putting me, and many others, in this very difficult and embaressing situation.
I fully agree with Tim Mallalieu to recommend LINQ to Entities as the data access solution for your application
   Big thanks goes out to Marjan for sharing these photo’s. ps: I’m the guy with his arm under
Linq to Sql dead already?
Why should we believe anything anymore?
Wait for version 3.
If there is no version 3, then you know you made the right choice, if there is a version 3, you still made the right choice.
There are things I would love to say about this situation, but all I *will* say is.. all of us working on v1 saw it coming.
That said, the following things from LINQ to SQL need to be in LINQ to Entities before I will even bother to recommend it for most cases (obviously, there are cases for which it is, even now, the obvious choice). Check them off as you go along:
– optimization of queries: we did some fantastic work on the query translation pipeline. If that’s abandoned in place, you just wasted a couple million right there, that you’ll be asked even more loudly to implement.
– speed of pipeline. That’s one of the "lightweight" aspects folks are talking about. Don’t let Rico’s and Matt’s work go to waste.
– simplicity/"It just works" — I shouldn’t have to create three sides of the equation when I just want a direct mapping. I want the LINQ to SQL way by default; if I *choose* to make life more complicated for myself, *then* I can start overriding the model.
To everyone else:
I seriously doubt Tim’s statement can be construed by any reasonable person to mean "we’re removing LINQ to SQL from the framework". Nobody’s going to force you to use anything if what you need is already satisfied by what LINQ to SQL provides. Not for another seven years, at least. After that, .NET 3.5’s support (like .NET 1.1’s support) ends. Hopefully by then we have something better than either. I can’t imagine what it’ll look like, and that’s somewhat exciting.
What Tim’s statement *can* be construed to mean is that it is unreasonable to expect Microsoft to keep LINQ to SQL and LINQ to Entities seperate when forces on both sides are pushing for even greater similarity (despite the fact that this has been known to happen in the past). At some point, they have to merge. The superset of support (particularly third party support) is on the LINQ to Entities side, and so futhering LINQ to Entities should be of no surprise. I have nearly two years of my life invested in LINQ to SQL’s internals, and despite that, I cannot disagree with the choice they’ve made. I am disappointed that one of the most fascinating projects I’ve ever worked on is going to not be advanced as much as I’d have hoped, but I feel they are making the correct decision for the Framework and, by extension, the customer base. They can *still* do work to push as much of what made LINQ to SQL work into Entities, and if they succeed there, it’s no waste.
LINQ to SQL was a fantastic piece of work, arguably the crown jewel of all of Orcas. LINQ to Entities has some things it needs to do in order to shine in the way LINQ to SQL did, but ..
.. it’s all still LINQ. It *can* shine, and your programs wouldn’t need to change much. LINQ, above all else, makes this much less painful than before.
A bit late, but it was still in my drafts folder, I just had to finish it. Timothy Mallalieu presented
@Keith,
I am tired of people saying, "They’re not killing, its still there in the framework if you want to use it." No one believes that it is actually being removed, but that doesn’t change the fact that it IS dying. I am not concerned about not being able to compile my L2S application against the next framework version. My concern is that when the next generation of features comes out, rather than being able to add them to my application incrementally, I am going to have to rewrite my application to use a completely different technology first.
Truthfully, all I really want is some honesty. Someone needs to come out and say, "Sorry guys, releasing two completely separate technologies with almost the exact same usage scenarios at almost exactly the same time was a big mistake. We are going to do the best we can to rectify the situation going forward, but we realize that for many of you who listened to our advice and bet on the technology we are now dumping, this is a major inconvenience. Our bad." But no one will do it; no one will even come close to offering an apology. And that gives me very little hope that anyone in Redmond is actually learning from this debacle, which in turn raises significant doubt in my mind about continuing to invest my job and my career in .NET.
I don’t believe MS anymore.
I don’t believe in MS anymore.
Switching to j2e in 6 month… thank guys from Redmond.
Just give the Linq to sql back to C# compiler team again …
@kage — data access is not the mandate of the C# compiler team. As a current stockholder MSFT, I wouldn’t support such a decision. I want the C# compiler team to work on C#.
@David — welcome to technology? .NET 2 will be dead in 5 years or so, if it follows the same schedule as .NET 1.x. In any event, you are exaggerating for dramatic effect with the words "completely different technology". Would you have to adjust some things? Yes, but you won’t have to rewrite queries on the same scale as, say, TSQL/MySQL rewrites. Use IQueryable, then change where you get it from, and let the underlying platform take care of things.
As for the honesty part, read Matt’s post from a while ago. It says all that I think anyone should say. Reread the first line of my comment; I don’t work for the company any more, and even *I* don’t feel like talking about it.
@roger_taylor — good luck. From the horror I’ve been through with it, J2EE takes six months to write "Goodbye, cruel world." 😉
@Keith,
.NET 1.1 didn’t die, it evolved into .NET 2.0, which evolved into .NET 3.5, (.NET 3.0 wasn’t so much an evolution as the intermingling of new DNA), which is evolving into .NET 4.0. New features are continually being added to the platform, and as I upgrade my project from one version to the next, I can incrementally add those new features where appropriate. LINQ to SQL, on the other hand, is not evolving, it is dying. The best I can hope for is another breed which is close enough that I won’t have to go through too much pain (and explanations to my boss) during the crossover.
You may not work for the company any more, but those who do are responsible to their customers. I am not sure what you are referring to when you say "Matt’s post from a while ago," but I have not seen anything from the data team or anyone at Microsoft that comes anywhere close to an acknowledgment that a fundamental mistake was made. Without that, I have no reason whatsoever to believe that anyone involved has the slightest idea the effect that their decisions are having on the community and the industry. I also have no confidence that the same mistake will not be made over and over again.
I always get the same question about the future of LINQ to SQL. Finally the ADO.NET Team, which is supporting
@David
Matt == Matt Warren, architect of LINQ to SQL v1. http://blogs.msdn.com/mattwar
No, they have more than the slightest idea.
Frankly, I’ll be using LINQ to SQL for 7 years. It does most everything I need, and I know how to get it to do most of the things it does not that I would like it to do.
You, if you wanted, *could* try out the LINQ to RDBMS stack that the Mono folks are coming up with. I haven’t examined them at all deeply, but LINQ is LINQ.
So given I have visual studio 2008 and 3.5 framework, what do I use?
Do I use ADO.NET Entities?
Linq to SQL Entities isn’t out yet, is my understanding.
Where are some good tutorials on ado.net entities? I’ve checked out the stuff on the ado.net page and they seem like old stuff that doesn’t work right with the new stuff.
I’m getting frustrated trying to find anything on ado.net entities.
The subject of this blog was:
Clarifying the message on L2S Futures."
and it starts with a question that diverts the real issue ata hand .. the question goes : "Is LINQ Dead ??" and the answer was : " No heck no .."
The question should have been : "Is LINQ to SQL Dead ??"
.. and from your article the answer is Clearly : "Yes !!"
I adore Microsoft for making us waste our time in learning L2S and start using it in developing real applications .. and suddenly the lights are switched off !!!
Why not move both products L2SQL & Entity framework in a direction that will result in a single prodcut range ..
Perhaps a product called EF Lite & EF
In the past when develping SQL apps one was always direted to use the native providors and libraries for SQL and avoided the general ODBC …
In the future I would see developers writing for EF and targeting a range of DB technologies .. but this will lack specifc features for the DB technology ..
Think about HierarchyID , and Table Types , Linked File ..
surely all these features are not implemented by all DB vendors ..
In conclusion .. MS SQL specific dev libraries and tools be it .. "Linq 2 SQL" or "EF for SQL" is a must !!!
because in all cases generic data access technologies targeting multi DB platform will never be as efficient as native tools that directly talk to the DB ( in our case MS SQL Server) !!
I have got to admit this REALLY pisses me off, I don’t want this to come off as unprofessional but Linq to EF is a convoluted POS compared to Linq to SQL. Right now Linq to SQL is not "dead" but what happens when SQL 20XX comes out and no additional support is added to Linq to SQL? I have yet to find ANYONE who supports the LINQ to EF over LINQ to SQL and the prevailing view seems to be the ADO.NET team favored their product internal product customer be d#*&%^.
Since Visual Studio 2008 SP1 you may have noticed 2 projects template for dynamic data: So what is the
Since Visual Studio 2008 SP1 you may have noticed 2 projects template for dynamic data: So what is the
LINQ to SQL *must* continue to be supported AND developed. If you let it die by neglect you will hurt your credibility – people make decisions (read: $$$) based on Microsoft’s pronouncements and development plans. I spent six months re-architecting my app to use LINQ to SQL.
In 2007 LINQ to SQL is the star, ScottGu does demos and there are loads of books appearing. Twelve months later and LINQ to Entity Framework is the "in-thing" and LINQ to SQL gets tossed in a cupboard. So what is there to say this won’t happen to L2EF in 2009? Should we trust or rely on anything that Microsoft says or is it all just marketing hype?
I am not sure this blog entry really tells me L2S is loved and cared for, just "supported". Give us some confidence and a roadmap – give LINQ to SQL a future!
Loving EF and looking forward to improvements. Glad to hear L2S is being killed.
<p>Tim Mallalieu, PM of LINQ to SQL and LINQ to Entities, recently <a href="http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx"
Tim Mallalieu, PM of LINQ to SQL and LINQ to Entities, recently announced: “…as of .NET 4.0 the Entity…
We have been troubled by a 'rumour' that Linq is dead … a strange rumour, because we are currently
Yes… and for those of us that understand your post STILL disagree. You’re making this decision because it helps benefit you and only you. I now see that there’s no going back since you have invested YOUR precious time into Windows Azure with EF.
What about your customers? What about those that have invested much more in time and money that are now going to lose out because they’re chosen product is now on the back-burner for you.
I’m sorry, Microsoft — but if you don’t react quickly you’re about to lose quite a few customers.
You have given us the boot, albeit in a very polite way.
How many different failed data access technologies has Microsoft produced? You finally get your best engineer(s) (Anders) to finally build something that really works well for everyone, and promptly abandon it. Microsoft is like a chicken in the headlights at the moment!
We’re all going to use Hibernate. Honestly I believe that’s mroe reliable than you guys. I feel cheated and slighted. Not to mention the fact that I am going to look like a complete idiot at work when we have to change yet again.
This behavior of abandoning technologies so carelessly, bring high level of doubtfulness in using the new technologies. For example I have not started to use WF and WCF yet. What if they are disappear in next version? Microsoft always have technology collisions because being property is somehow in conflict with being productive. LINQ to SQL is a very well designed piece and I see why it must be abandoned: It is too high level to be totally dependent on SQL Server!
And is not WF a rival for BizTalk? And WCF a rival for Windows Azureus service oriented design?
This kind of decisions makes .NET development too expensive and too risky to rely on in enterprise.
I really hope Microsoft "understand" this.
Best Regards
[quote]
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.
[/quote]
Can anyone explain what ‘triangulating with regards to overall convergence means’?
"Thanks for putting me, and many others, in this very difficult and embarrassing situation." where we have to explain why the heck we spent so much time understand and use Linq to sql, and then explain that it would ditched for something far worse.
-Rafi
Ok, we all know there are waaaaay too many ingredients in this data access soup in the Microsoft stack. So, please don’t add to the confusion but changing your mind later again. I completely understand your rationale for going with LINQ-EF and that is fine. Just PIN IT DOWN!!! AND MOVE FORWARD!!!
I haven’t seen that many developers use LINQ anyway, so it’s not too late to make such big shifts in direction. JUST PLEASE settle on this and don’t change it again in a couple of month. Forget having additional support for Linq-Sql, let’s just consider it deprecated and move on.
I second what so many other people have been saying — if you don’t want to spend time working on LINQ to SQL, then please open source it so those of us who have already invested in it can improve it.
LINQ to Entities may be your "preferred" solution, but most people I’ve talked to don’t plan on using it for awhile and would much rather use L2S. Also, if and when L2E gets up to par, there will still be tons of people out there that are heavily invested in L2S because it was the best option when they had to make their decision.
No doubt that we have been cheated by Microsoft this time.
From the comments above Microsoft should know lots of developers love L2S. However. they don’t care.
Wonder if we should invest any time any more on those new Microsoft technologies such as Silverlights and Dynamic Data as they may also not "supported" shortly.
LINQ to SQL (and any ORM for that matter) has the marmite factor. You either love it or hate it. Whats
I don’t read that L2S is dead. I read that its features are being merged into L2E over time.
That seems like a smart move.
Except for shops that really do like have different code paths providing related functionality. Which seems dumb.
Save the handwringing for when L2S suddenly disappears off the face of the earth with no actual representation in L2E.
I agree with Andy. Having invested considerable effort in L2S (to work with the latest and the greatest), I will probably be more careful in the future, not touching new technologies like Silverlight too early.
EF Team spitted fire on C# Team. Microsoft’s managers waded wars. Hundreds of developers dead. I think Bill Gates should be back to sort out the mess.
EF’s development dates back years and years, and I fully expected that the EF v1 was much better than Linq to SQL. It turned me off to know that it simply can’t do implicit lazy loading. The Single() extension method throws the NotSupportedException. And all those bits that screwed up N-Tiers.
Now it is good to know EF 2 will rid some of the showstoppers. But would you mind telling us the ETA? Since you have just said that EF development is now more open. We are hanging on the line right now, because ADO.NET is dead, Linq 2 SQL is now dead, and EF is not usable. What are we going to use for the next 12 months?
Please, please, put more man power in EF. Please ask C# team to join hands.
Neo
So PDC is over for this time, but PDC 2009 is already announced, so we might not need to wait three years
You are killing one of the few good producting MS has ever developed. Tells us lot about your credibility.
I really get disappointed as i investigate a lot of time in learning Linq to SQL, then i try to think what to do after reading ADO team posts, i take a look at Entity Framework and it didn’t meet my needs it’s very complex. Linq to sql is similar to Active Record Pattern and Entity Framework similar to Domain Driven Design. i don’t like Domain Drive Pattern because it costs a lot of time. so the decision of discontinue Linq to SQL is not a good decision. Linq to SQL is one of things made me move to asp.net last year. Now i think that i fall in big problem to depend on MS products and may be try to use something different may be SubSonic or back again to PHP and use Zend Table Data Gateway with Zend Framework
I think it makes sense for MS to merge the two technologies into one that scales both for simple and complex scenarios. I hope they will pump the power & quality of L2S-SQL-Generation + simplicity into L2E (watch http://channel9.msdn.com/pdc2008/TL20/ for more info about EFv2).
I have some years of Java background and the situation there was much more worse: EJB 1 was unusable which was partly fixed in EJB 2 just to get completely rewritten with EJB 3. Besides of that Sun invented JDO as the answer to Hibernate. So watch out you wanna-be-converts, there is no paradise out there waiting for you.
So today I would tend to NHibernate because EF2 is still a long time to wait for. But then it will be a good solution.
The talk that Mike posted above is great. For those of you pressed for time, jump in around the 30-minute mark, and watch for the next 10. It goes over the use of POCO classes and some of the features of EFv2 that current L2S people would be looking for. No ssdl,csdl, or msl. Just classes mapped by convention or by attributes on the ObjectContext to your datastore. I can think of a number of ways that I could generate code to migrate my current L2S apps to use this approach.
On the topic of my L2S apps. They still work fine. They are not withering on the vine. If L2S is dead, it still appears to be alive enough to meet the needs that drove me to it in the first place.
It’s really a sad situation when you invest your time and money in new technologies and to see it abandoned
Thank you for making me look like an idiot, Microsoft. I spearheaded an effort to switch our data layer over to L2S because it had the backing of ScottGu and every other bigwig who maintains a blog. We switched over, and now you decide to kill it. My boss pointed me here and said he now has grave concerns over my decision making abilities. Thanks a lot. Idiots. So now you’ve gone ahead and screwed over my career. Quite frankly I don’t think I’ll be recommending any MS technologies in the future. If you can’t even stand by your own stuff, how can you expect others to?
Being a former Visual Foxpro developer I understand abandonment. Our chosen product was kicked to the curb years ago because it didn’t fit the Microsoft business model at the time. Link to SQL looked like the perfect path for data centric applications, but now that’s getting kicked to the curb as well. I know, I know – seven years until it’s abandoned. That’s cold comfort for us former VFP types.
I hope Microsoft develops a new business plan that will allow them to refine a technology to some level of maturity instead of simply dropping it to reach for the "next big thing". Ahh well – maybe time to explore alternatives…
The ADO .Net team should be ashamed. They developed an ORM tool/data platform that is despised for its complexity and poor quality. The C# team developed a competing platform that is simple, elegant, and consequently, loved. Then L2Sql was given into the hands of the ADO .Net team. So what does ADO .Net decide to do with Linq to SQL? KILL IT!
They can’t stand to have a brilliant and beautiful platform like Linq to SQL competing with their hideous child. If both were co-developed (like VB and C#) 90% of projects would use L2Sql.
I'm not dead or gone, just had a lot of work to do. Have started to record a lot of screen casts
I just have to say it somewhere… What really saddens me if the speed of EF. L2S is probably the fastest ORM there is for .NET. The SQL code it generates is optimal most of the times. EFs SQL is just SO bad.
I’ve done some research and made a comparison of NHibernate, L2S and Entity Framework (from SP1 BETA!!). It was not a micro-benchmark, it was based on the TPC-E benchmark. Entity Framework (BETA) lost in every scenario. My results were as follows:
EF (uncompiled LINQ): 99,46 tpm (transactions per minute);
EF (compiled LINQ): 815,46 tpm;
NHibernate (using HQL): 1637,70 tpm;
LINQ to SQL (uncompiled LINQ): 565,29 tpm;
LINQ to SQL (compiled LINQ): 1931,46 tpm;
I tried to use the best combination of ORM options (eager loading, optimistic concurency, change tracking, etc.) for every framework. EF is just SO SLOW and it implements just SO LITTLE of LINQ. Since L2S is good and NHibernate is good (but has bad tools) I recommend sticking with them. If you need extensive mapping functionality: choose NHibernate. If you can live with SQL Server, and your object model can be a little closer to the relational one: choose LINQ to SQL. I personally think it is the best ORM out there.
MS, pleaser reconsider your future support for LINQ to SQL.
Wow I thought everyone was using the EF and I was in the minority loving L2S…
At the very least it would be great to get pre-release bits for EF2 (Framework 4.0) going early and often.
That would be one way to start to re-build everyone’s trust quickly.
This is so frustrating. I guess I’ll switch to subsonic.
Getting started with Linq-To-Entities tutorial
Getting started with Linq-To-Entities tutorial
"Let me start by saying sorry for the radio silence since the post but, as Elisa mentioned, we posted it while at PDC and were focusing on the interactions there over the last couple of days."
Still at the PDC? Have you all been fired or what? After 3 months no comments have been answered in this blog. I guess that says it all really.
Can you guys let me know what time you really had to invest as far as learning L2S? Was it learning how to use O/R mapper? I am a relatively green developer and I started using L2S easily. It certainly didn’t take 6 months to get comfortable with -not even a week. I like it, but I never feel like I fully understand anything and to me that seems like a basic part of being a developer.
Yeah it’s an awesome tool, but LINQ will still be around and O/R mappers will always be around. They’re not going to get rid of something that obviously works well, EF will probably include something that makes it work just like you’re used to with L2S.
Can you guys let me know what time you really had to invest as far as learning L2S? Was it learning how to use O/R mapper? I am a relatively green developer and I started using L2S easily. It certainly didn’t take 6 months to get comfortable with -not even a week. I like it, but I never feel like I fully understand anything and to me that seems like a basic part of being a developer.
Yeah it’s an awesome tool, but LINQ will still be around and O/R mappers will always be around. They’re not going to get rid of something that obviously works well, EF will probably include something that makes it work just like you’re used to with L2S.
Now the date on the bottom of this page still saying 2008 -that worries me a bit 😉
Haha @ Entertaining, best comment.
This is newspeak at it’s best.
Hey Tim, how about some answers? Can you speak English too. I am your customer, this my feedback, you react, how hard can it be?
With the beta release of Windows 7, the announcements done at PDC in October 2008 around the Azure Services
After a year of working with LINQ to SQL, I strongly belivev that LINQ to SQL and Entity Framework (EF)
As part of my day to job I come across a very common question from the developer community that one should
I have a direct question for Tim that is a one word answer:
Is Linq to SQL dead?
(Yes or no)
We don’t want news speak or tap dancing… a yes or no is what we need.
Thanks!
I appreciate this post. I am starting a couple of new projects and betting data access on LINQ to Entities. Lets hope MS does not switch positions.
Thanks
This is the same exact nonsense MSFT pulled with Visual Basic and Visual FoxPro. Developers really need to stand up and say enuf of this crap. I’m completely FED UP with Microsoft, their utter incompetance and total disregard for their development community!
I started with a book Linq In Action and immediately saw results, productivity and a useful tool.
I’ve applied those techniques into new applications that have promise and a future.
I started with a book called Programming Entity Framework and immediately saw complexity, confusion, inconsistency and a dramatic drop in productivity.
So you have come to the conclusion that L2S is deprecated, and EF is the solution.
There is a reason that simple (REST) is elegant, and complex (WS*) is not heavily used.
Perhaps you should take a page from the elegant book and continue the evolution of L2S in tandem with EF.
IF as you say, EF is the way to go, then you will not need to cram it down our throats, and we’ll gladly follow a superior technical solution.
Announce an EOL on L2S only after you have actually produced the goods, and from what I have seen, EF will go the way of WinFS.
Looking forward to being proved wrong a PDC09, but by God you had better have your story straight or we will tear you apart in the sessions.
gonna be the complex EF – whether we like it or not. And guess what – those making the decision to keep EF and EOF L2S also happen to be the people who wrote EF and were competing with the L2S team in a turf war. What a coincidence.
Did you know that theres a provider model in L2S that lets L2S work other database providers – but they were forced to disable it for political reasons. The programmers writing L2S were forced to cripple L2S so that EF could compete. MS werent happy to let the market decide which technology should win cause they knew better than all their customers.
Sucks.
Hey Vince well said.
The successful technologies are the simple and elegant ones.
What sucks is that we never got the choice as programmers to decide which of L2S or EF should win out. MS decided FOR us – that it’s gonna be the complex EF – whether we like it or not. And guess what – those making the decision to keep EF and EOF L2S also happen to be the people who wrote EF and were competing with the L2S team in a turf war. What a coincidence.
Did you know that theres a provider model in L2S that lets L2S work other database providers – but they were forced to disable it for political reasons. The programmers writing L2S were forced to cripple L2S so that EF could compete. MS werent happy to let the market decide which technology should win cause they knew better than all their customers.
Sucks.
Microsoft Kills LINQ to SQL? For the last couple of months, I've been hearing all kinds of complains
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdowns
I really get disappointed as i investigate a lot of time in learning Linq to SQL, then i try to think what to do after reading ADO team posts, i take a look at Entity Framework and it didn’t meet my needs it’s very complex. Linq to sql is similar to Active Record Pattern and Entity Framework similar to Domain Driven Design. i don’t like Domain Drive Pattern because it costs a lot of time. so the decision of discontinue Linq to SQL is not a good decision. Linq to SQL is one of things made me move to asp.net last year. Now i think that i fall in big problem to depend on MS products and may be try to use something different may be SubSonic or back again to PHP and use Zend Table Data Gateway with Zend Framework
You guys have done a really bad job of muddying the landscape of development today. While at Telligent I wasn’t quite as involved in current day development and trends, now that I’ve jumped back into things I find the current day lay of the land to be quite confusing.
You have introduced L2S, L2E and EF now. And, for whatever reason, it appears that you’ve standardized on what I’ve read, and heard, to be the worst of the three.
I’m glad to be a seasoned technologist who can research and sort through these things, but I feel sorry for the newer developers who are trying to make sense of it all – you’ve done nothing but muddy the waters for tomorrow’s developers at the sake of some developers’/teams’ goldplating.
That’s very, very disappointing.
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdowns
Very good, congratulations article
I am grateful to you for this great content.
I really get disappointed as i investigate a lot of time in learning Linq to SQL, then i try to think what to do after reading ADO team posts, i take a look at Entity Framework and it didn’t meet my needs it’s very complex. Linq to sql is similar to Active Record Pattern and Entity Framework similar to Domain Driven Design. i don’t like Domain Drive Pattern because it costs a lot of time. so the decision of discontinue Linq to SQL is not a good decision. Linq to SQL is one of things made me move to asp.net last year. Now i think that i fall in big problem to depend on MS products and may be try to use something different may be SubSonic or back again to PHP and use Zend Table Data Gateway with Zend Framework
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdowns
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdowns
We should write to Bill Gates instead of talking to ignorant people at L2E-team 🙂
I am tired of people saying, "They’re not killing, its still there in the framework if you want to use it." No one believes that it is actually being removed, but that doesn’t change the fact that it IS dying. I am not concerned about not being able to compile my L2S application against the next framework version. My concern is that when the next generation of features comes out, rather than being able to add them to my application incrementally, I am going to have to rewrite my application to use a completely different technology first.
This sucks! I love L2S. I have invested in it. And I agree with most of the comments here. So listen to the comunity! If you don’t change your mind, I am switching to Oracle!
this is awful.
we were about to switch to ms from java but stopped because of all the change.
This is another example of Microsoft developing a product that developers begin to use instead of forcing developers to learn how to do it themselves. A thorough understanding of the hows and why of the DAL is far better than relying on a product that will most likely be phased out on a whim. I would far rather extend the functionality of the Enterprise Library (that team has it together) and build a truly useful DAL that is conducive to multiple layers.
Ha – Linq to Sql has a shorter life span then Visual Foxpro~ Can someone please remind me how many data access strategies were tried in Visual Studio already? What is so freaking hard about this?
http:\dotbloat.blogspot.com
L2S is light weight and good ORM for general usage.
I don't know why microsoft make it die.
Although i know EF is powerful then L2S, and i have use L2S and EF in this 2 years,
even i already turn to EF for my work, but not everyone have to develop is enterprise project, right?
.NET dev team get a wrong direction.