Clarifying the message on L2S Futures.
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
Comments
Anonymous
October 31, 2008
PingBack from http://mstechnews.info/2008/10/clarifying-the-message-on-l2s-futures/Anonymous
October 31, 2008
The comment has been removedAnonymous
October 31, 2008
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.Anonymous
November 01, 2008
The comment has been removedAnonymous
November 01, 2008
Negli ultimi giorni la notizia sono rimbalzate. Forse troppo. Ad una prima lettura non mi era sembratoAnonymous
November 01, 2008
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 MilanAnonymous
November 02, 2008
The comment has been removedAnonymous
November 02, 2008
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?Anonymous
November 02, 2008
To make a long story short: the ADO.NET team is now responsible of ADO.NET Entity Framework (includingAnonymous
November 02, 2008
To make a long story short: the ADO.NET team is now responsible of ADO.NET Entity Framework (includingAnonymous
November 02, 2008
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.Anonymous
November 02, 2008
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.Anonymous
November 02, 2008
off-the-topic: when will oracle provider for EF come out?? we are longing for it over 1 year~~~Anonymous
November 02, 2008
The comment has been removedAnonymous
November 02, 2008
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, MilanAnonymous
November 02, 2008
The comment has been removedAnonymous
November 02, 2008
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.Anonymous
November 03, 2008
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.Anonymous
November 03, 2008
There is a lot of comment around recent pronouncements from the ADO.NET team that their future strategyAnonymous
November 03, 2008
There is a lot of comment around recent pronouncements from the ADO.NET team that their future strategyAnonymous
November 03, 2008
The comment has been removedAnonymous
November 03, 2008
...and the "asks" from users...???? Next time, could you please speak English?Anonymous
November 03, 2008
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.Anonymous
November 03, 2008
I fully agree with Tim Mallalieu to recommend LINQ to Entities as the data access solution for your applicationAnonymous
November 03, 2008
   Big thanks goes out to Marjan for sharing these photo's. ps: I'm the guy with his arm underAnonymous
November 03, 2008
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.Anonymous
November 03, 2008
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.
Anonymous
November 03, 2008
A bit late, but it was still in my drafts folder, I just had to finish it. Timothy Mallalieu presentedAnonymous
November 04, 2008
@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.Anonymous
November 05, 2008
I don't believe MS anymore. I don't believe in MS anymore. Switching to j2e in 6 month... thank guys from Redmond.Anonymous
November 05, 2008
Just give the Linq to sql back to C# compiler team again ...Anonymous
November 05, 2008
The comment has been removedAnonymous
November 05, 2008
@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.Anonymous
November 06, 2008
I always get the same question about the future of LINQ to SQL. Finally the ADO.NET Team, which is supportingAnonymous
November 06, 2008
@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.Anonymous
November 07, 2008
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.Anonymous
November 08, 2008
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) !!Anonymous
November 09, 2008
The comment has been removedAnonymous
November 09, 2008
Since Visual Studio 2008 SP1 you may have noticed 2 projects template for dynamic data: So what is theAnonymous
November 09, 2008
Since Visual Studio 2008 SP1 you may have noticed 2 projects template for dynamic data: So what is theAnonymous
November 09, 2008
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!Anonymous
November 10, 2008
Loving EF and looking forward to improvements. Glad to hear L2S is being killed.Anonymous
November 10, 2008
<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"Anonymous
November 10, 2008
Tim Mallalieu, PM of LINQ to SQL and LINQ to Entities, recently announced: “…as of .NET 4.0 the Entity...Anonymous
November 11, 2008
We have been troubled by a 'rumour' that Linq is dead ... a strange rumour, because we are currentlyAnonymous
November 11, 2008
The comment has been removedAnonymous
November 11, 2008
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.Anonymous
November 11, 2008
The comment has been removedAnonymous
November 11, 2008
[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'?Anonymous
November 12, 2008
"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. -RafiAnonymous
November 12, 2008
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.Anonymous
November 14, 2008
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.Anonymous
November 15, 2008
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.Anonymous
November 15, 2008
LINQ to SQL (and any ORM for that matter) has the marmite factor. You either love it or hate it. WhatsAnonymous
November 20, 2008
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.Anonymous
November 24, 2008
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.Anonymous
November 25, 2008
The comment has been removedAnonymous
November 25, 2008
So PDC is over for this time, but PDC 2009 is already announced, so we might not need to wait three yearsAnonymous
November 28, 2008
You are killing one of the few good producting MS has ever developed. Tells us lot about your credibility.Anonymous
November 28, 2008
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 FrameworkAnonymous
November 30, 2008
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.Anonymous
November 30, 2008
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.Anonymous
November 30, 2008
It's really a sad situation when you invest your time and money in new technologies and to see it abandonedAnonymous
December 02, 2008
The comment has been removedAnonymous
December 02, 2008
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...Anonymous
December 06, 2008
The comment has been removedAnonymous
December 13, 2008
I'm not dead or gone, just had a lot of work to do. Have started to record a lot of screen castsAnonymous
December 29, 2008
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.Anonymous
December 31, 2008
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.Anonymous
January 06, 2009
This is so frustrating. I guess I'll switch to subsonic.Anonymous
January 08, 2009
Getting started with Linq-To-Entities tutorialAnonymous
January 15, 2009
Getting started with Linq-To-Entities tutorialAnonymous
January 17, 2009
"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.Anonymous
January 21, 2009
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.Anonymous
January 21, 2009
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 ;)Anonymous
February 04, 2009
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?Anonymous
February 15, 2009
With the beta release of Windows 7, the announcements done at PDC in October 2008 around the Azure ServicesAnonymous
February 17, 2009
After a year of working with LINQ to SQL, I strongly belivev that LINQ to SQL and Entity Framework (EF)Anonymous
March 07, 2009
As part of my day to job I come across a very common question from the developer community that one shouldAnonymous
March 16, 2009
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!Anonymous
March 18, 2009
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. ThanksAnonymous
April 01, 2009
The comment has been removedAnonymous
April 07, 2009
The comment has been removedAnonymous
April 09, 2009
The comment has been removedAnonymous
April 09, 2009
The comment has been removedAnonymous
April 10, 2009
Microsoft Kills LINQ to SQL? For the last couple of months, I've been hearing all kinds of complainsAnonymous
April 10, 2009
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdownsAnonymous
May 21, 2009
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 FrameworkAnonymous
June 03, 2009
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.Anonymous
July 04, 2009
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdownsAnonymous
July 17, 2009
Very good, congratulations articleAnonymous
July 18, 2009
I am grateful to you for this great content.Anonymous
July 19, 2009
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 FrameworkAnonymous
July 23, 2009
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdownsAnonymous
July 23, 2009
For the last couple of months, I've been hearing all kinds of complains, cries, nervous breakdownsAnonymous
October 16, 2009
We should write to Bill Gates instead of talking to ignorant people at L2E-team :)Anonymous
December 25, 2009
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.Anonymous
January 14, 2010
The comment has been removedAnonymous
January 18, 2010
this is awful. we were about to switch to ms from java but stopped because of all the change.Anonymous
January 19, 2010
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.Anonymous
December 16, 2010
The comment has been removedAnonymous
May 28, 2011
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.