LINQ to SQL next steps
- 📅
- 📝 625 words
- 🕙 3 minutes
- 📦 Microsoft
- 🏷️ Entity Framework, LINQ
- 💬 25 responses
There has been a flurry of posts and comments in the last 24 hours over the future of LINQ to SQL so I thought it would be interesting to provide some information on what the LINQ to SQL team have been up to and what we’re working on for .NET Framework 4.0.
A little background
LINQ was a new feature in .NET 3.5 that provides a store-agnostic query language syntax using a provider model.
As part of that initiative the C# team delivered LINQ to SQL — a LINQ provider to SQL Server with additional update and access management via DataContext and mapping tools such as the designer and SQL Metal. The result is a great lightweight solution that is easy to get started with and a good data access solution where your database and objects are closely aligned.
Meanwhile Data Programmability worked on an initiative to provide abstraction between conceptual and physical models of databases to allow applications to operate independently of the database vendor and underlying physical schema. LINQ support was also added in the form of LINQ to Entities and it shipped with it’s management tools in .NET 3.5 SP1.
Which now means we have two object-relational mapping options that overlap in some areas but with very different backgrounds.
The story so far
Some time before I started in May LINQ to SQL was handed over to Data Programmability.
One of the first things you notice is that the overlap between the two object-relational mapping solutions Microsoft causes confusion and hesitation.
Do I want something lightweight and easy or do I need the extra abstraction with a richer feature set?
If I want to start with LINQ to SQL today but know that the database won’t stay under my control how would I move to Entity Framework?
These are the questions that many developers face and our team spent a lot of time looking at the differences between the two stacks, how they behave and which features were missing if you wanted to migrate from LINQ to SQL to Entity Framework v1. We put together code samples, some helpers and documentation which are now being serialized on the ADO.NET blog and left us with a better understanding of the disparity — some of which the EF team have already addressed in v2.
Where next
The decision has been made that Entity Framework is the recommended solution for LINQ to relational scenarios but we are committed to looking after our users and are approaching this in two ways.
Firstly we are going to make sure LINQ to SQL continues to operate as it should. This doesn’t just mean making sure what we had works in .NET 4.0 but also fixing a number of issues that have arisen as people pick it up for more advanced projects and put it into production environments.
Secondly we will evolve LINQ to Entities to encompass the features and ease of use that people have come to expect from LINQ to SQL. In .NET 4.0 this already includes additional LINQ operators and better persistence-ignorance.
This isn’t to say LINQ to SQL won’t ever get new features. The communities around LINQ to SQL are a continuous source of ideas and we need to consider how they fit the minimalistic lightweight approach LINQ to SQL is already valued for. Where these suggestions fit with this strategy we will be working hard to get them into the product. Some enhancements like the T4 templates can be released independently but run-time elements need to stick to the .NET Framework schedule.
In conclusion
DON’T PANIC (in large, friendly letters)
LINQ to SQL will continue to work and EF will better address the needs of LINQ to SQL users with each new release.
[)amien
25 responses to LINQ to SQL next steps
I have been using L2S for the last 1–2 months & really love it.
ASP.Net MVC, jQuery & L2S is my current technology stack.
I was wondering if MS would prefer to open source L2S implementation so that the interested community can take it forward.
I think this could be a win-win situation for all concerned…
My 2 cents
Thank you for the post! I have used Linq to Sql in several of my Enterprise Applications and I can tell you first hand that the performance is mind blowing.
Within the first month of using Linq to Sql, our development cycles got cut down by 30%, our error rates in DAL Layer dropped to a virtual zero, and the best part was, there was almost no performance penalty.
I have played around with EF, NHibernate (used previously in 2 enterprise apps) and Linq to Sql. The only thing that I see with Linq to Sql is, that it’s tied to SQL Server. But we are a Microsoft shop and we do all our development in SQL Server, which is not a bad thing. So Linq to Sql does work out great.
I have an application that gets to the tune of 40,000+ hits per month and I am yet to see any issues with Linq to Sql. So if I know that SQL Server is being used, I would use Linq to Sql over EF. There are a bunch of things in EF that make me want to wait for a future release. NHibernate definitely takes the cake in almost everything (love their Criteria API for ad-hoc queries), but I hate the way CodeSmith templates are generated for the same. So I use it only in scenarios where I have tremendous amount of ad-hoc querying required.
So for the time being, I am sticking to Linq to Sql. Also glad to know that Linq to Sql is not going away! It is a little too tight to just throw away. Not to mention the queries generated by it are infact better than EF (or am I just dreaming this?)
I don’t know if it is right to call it an OR/M, but it gets the job done pretty good!
Thanks! Keep up the good work!
The only problem with LinqToSql is enterprise design. MSDN and microsoft samples are limited to LinqDataSource. Even, pure design for DataContext across layers are defined as patches by community and never defined by microsoft.
They mixed object creation and tracking in datacontext leading enormous problem design issues.
Hope microsoft will find out a better pattern for multi tier architectures.Yes, codeproject and other articles exists, but they are workarounds.
@TT: LINQ to SQL can definitely be used for much more than simple sites and RAD — the only real restriction is that your database and the objects it creates are very tightly coupled and it is SQL Server only.
The teams responsible for EF and L2S are now located right next to each other and there is collaboration between the teams in closing the gap for .NET 4.0.
It’s not fair to say team a did a better job than team b because they had different objectives. LINQ to SQL’s objective was to allow LINQ queries to work with a database. EF’s objective was to provide conceptual to physical data modelling that is independent of storage location/provider.
Firstly I don’t know where the Linq2sql is only fit for RAD development and simple sites rumors come from. Is it just because Entity framework is a more complex application that leads people to believe it automatically handles more complex structures better? It has been proven many times that Linq2sql generates much better sql than entity framework and probably would handle a larger database better as well.
I was always under the impression that when Entity framework was released there would be no more need for Linq2sql and we could easily port over our data layers, but the obvious lack of communication between the 2 teams has lead to 2 quite different architectures so I among many others have little faith in that even EF v2 or v3 will give us anything close to the user friendliness of Linq2sql.
The fact that Linq2sql is a superior product to Entity Framework v1 and that the ADO.NET team seems so reluctant to admit that the C# team actually did the job they were supposed to do so much better puts the ADO.NET team in a bad light. The ADO.NET team could learn some communication techniques from the asp.net mvc team and try to appear a bit more pragmatic.
I love Ling to SQL as well I have tried EF and well. EF just makes me wade through so much industrial waste to get what I want from linq to SQL in a matter of pressing tab and 1 letter 30 some times. Now I do like how EF handles a few other things, as I can use EF as my “central” language when I am talking to a DB2 we have that needs to run up against a SQL. While my backend is different, I have the same “frontend” which is nice.
However for the simple I want X,Y data from sql (my main db since after all I am a microsoft shop why would I be running anything but SQL if I am coding asp.net / ajax / silverlight. I know I could, just saying having it all MS just makes sense. L2Q just works so perfectly. Now I understand the whole point MS has of not wanting to replicate a bunch of code, and “wasting” resources on making 2 similar projects that greatly overlap, however merging the 2 together while keeping the calls to L2Q simple I dont mind if I have to make a long declaration of a class. Just allow me to make that declaration and then have my L2Q setup inside of EF. Or let me back up out of the class tree and return to normal EF.
I know it’s much more complex then just that, but that type of merger would make both camps happy, I think. :)
I love Linq to SQL. We have all of our contractors spent 2 days learning it and then they are 5–10 times more productive with less errors. Linq to SQL (and of course Linq) is one of the greatest things Microsoft has ever done. I think the only people who don’t like it are people who have never used it to deliver a fulll product. You simply can not go back :)
Considering the success of Hibernate and like-minded technologies have enjoyed for many years, it was refreshing to see the language group produce a similarly successful technology. Not surprising as C# is truly an excellent language on a smooth evolutionary path. LINQ itself is revolutionary. In contrast, the data access group turns out one incompatible flush-and-rewrite after another. Avoiding their output like the plague has proven to be a wise decision. Off topic: when can we expect dependency injection in C#?
This is absolutely fantastic news, Linq to Sql is the best data access technology for .Net and Sql Server to use when you want a lightweight data access layer under your business layer or do ad hoc data access easy without the complications EF provides (so far). But the “lighness” of Linq to SQL is it’s biggest plus over any other similar technologies. I love Linq2Sql.
I think that this approach is a good one. L2S spring out of Matt Warrens attempt on a LINQ to Object Spaces pet project when the C# team waited for a proper LINQ provider to show up (WinFS as I understood it then), and Object Spaces was killed the first time around for a reason.
Also, I don’t understand all this talk about L2S being the “recommended data access technology” I’ve must have missed a white paper or something. AFIK the story has always been, L2S — Lightweight RAD tool for small throw-away apps, EF — Enterprise worthy data access.
So if you built your enterprise applications on L2S, you just haven’t followed the recommendations.
Just (well, not really; this is a serious question) to further muddy the waters… I happened on a link to a link to Oslo. Now, that’s some ambitious blingbling. Some may not be old enough to remember Model Driven Architecture, but Oslo (I’ve scanned some part of the site, maybe 50%) is a serious (in level of face validity) effort.
Is there any relationship among the three? Either now (not mentioned, so likely not), or in the future? Is Oslo destined to consume both?
Hi Damien,
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).
I want also thank you for your discussing with us — from the ratio of comments from programmers and responses from anybody from MS — it seems to me that you are the only one in MS which ever met L2S and EF :)
Best regards, Milan
Hello, I just finished building my first application using LINQ, and I LOVE IT! I am a huge fan and tell other developers that I couldn’t have built the application as quickly without using LINQ. I am learning it with great enthusiasm. I can’t believe that the people saying LINQ is no good have ever even given it a chance. It allows for querying the database objects straight from code, and accessing values in lookup tables by drilling through the database model. Perfect! Please, keep up the good work and continue to grow LINQ, for the sake of developers who have learned that it’s a wonderful tool!
As you would probably know, I’m rather happy with this news and wish it would happen sooner
I am not an expert on either L2S or EF, although Microsoft’s decision to focus on making EF good rather than funding two overlapping competing technologies makes plenty of sense to me. Also, if we look at the distribution of social skills and civility, the ‘OMG they killed L2S’ crowd lose big time. Sorry guys.
@Milan: There isn’t a definitive timetable as it is an ongoing process. EF v2 makes many improvements and we’re going to keep refining. Some of the tools such as helpers, wrappers and additional tools could happen out of band :)
EF has a different set of objectives to NHibernate and a broader design that could encompass LINQ to SQL scenarios. Trying to stretch LINQ to SQL to achieve EF’s objectives would be an unlikely success while also dragging LINQ to SQL away from its lightweight strengths.
I don’t have any EF samples to hand — somewhat overloaded with these responses — but a and b should be almost identical code to LINQ to SQL and all three are being covered in the multi-part series on the ADO.NET blog.
Two different teams going in two different directions would mean more overlap, more confusion, more resources and increase the difficulty in switching at a later date if you find the feature sets you want turning up on the other stack.
Hi Damien,
Best regards Milan
Okay, here’s my personal response to some of these comments.
@Parag: I wasn’t at Microsoft when that happened. I would imagine LINQ was important enough to ship with a SQL provider and EF wasn’t ready.
@MichaelGG: The internal provider model won’t go public. Writing your own provider is a complex task — the SQL Provider in LINQ to SQL represents around 70% of the runtime source. If you’re replacing 70% of the product and the mapping tools you may as well write your own LINQ provider and skip LINQ to SQL.
@Kristofer: I’ll see if we can get a list out.
@Ori: People tell us they like LINQ to SQL because it’s lightweight and simple. We’re not putting the product in maintenance mode but keeping it focused.
Just because a class or namespace doesn’t get a whole bunch of changes between releases doesn’t mean it’s dead or that you should avoid using it. Some of the fixes we’re doing are for better scalability and for usage scenarios which are improvements everyone gets for free without API bloat.
I’m not really in the business of developing transactional business apps anymore, but when I was this kind of ‘hopping’ between recommended APIs was the norm in the Microsoft camp, and one of the things that made me nervous about developing anything seriously long-term on .Net for fear of being left on the ‘wrong’ technique after 12 months (and a new version of Visual Studio). Now, API hopping happens everywhere — in the Java world we always had lots of different ways to do persistence, but the difference was that control was far more decentralised, since most of the implementations were open source. There wasn’t really any ‘deprecating’ of previous techniques as such, since those projects would normally continue as long as there was an interested community using them.
I’m sure L2SQL will be the same to a degree, but the fact that it is 100% controlled by MS and closed source means exposure to deprecation and isolation is more of a concern to users. I hope MS learn from this, and consider open sourcing future important parts of their software stack (compatible with their increasingly open approach), to give people who invest seriously in their technology some insurance over changes in strategy like this. It really does work — if you gave L2SQL to the community to look after, it would probably enjoy a more active future than it will as a ‘no preferred’ technique inside Microsoft, and give people more reassurance that their own investment in the tech isn’t in so much jeopardy.
Damien,
Glad to have this input, which clarifies the situation better than Tim Mallalieu’s recent repetition of his first post.
--rj
Damien,
Thank you very much for the clarification.
The main issue here is the issue of trust. As Microsoft holds all of the rights to Linq2SQL, the developers out there invested in Linq2Sql and trusted that Microsoft will continue to evolve the technology. What you are describing is an abandonment of the technology, as Linq2Sql is going into maintenance only mode. So there is some broken trust here.
For me personally this raises fears about the future of the Entity Framework. What assurance do I, as a developer, have that Entity Framework will continue to be developed into v3 and v4? Will it not be abandoned in the same way?
Perhaps if you could expand on the how the decision was reached and what were the deciding factors I, and others, will feel more assured that the Entity Framework won’t end up in the same state.
Ori
Excellent summary. I wish Tim’s original blog post had explained it this way and all the negative PR would have been avoided.
It would be interesting if you could provide a summary of some of the anticipated changes to L2S in .net 4 (bug fixes etc that you mentioned above). (Or just links to the relevant MS Connect items). Just some hints, some candy, it’s halloween after all… :)
I have noticed that some .net 3.5 RTM issues were fixed in .net 3.5 SP1 but not documented anywhere (that I can see). E.g. some complex Linq queries are translated to much more efficient SQL in SP1 than it was in RTM.
What about the internal LINQ-to-SQL provider model? Will that go public so other companies (say, VistaDB) can add their support? For many things, LINQ-to-SQL is just perfect: provides easy objects and query support, and with a tiny bit of generic helper methods, CRUD. I don’t want entities or some big framework all the time. I just want real simple “hey, here’s your table, so here’s your object”.
Hi Damien,
My only complain is if Microsoft was going to make judgements and conclusions, why it didn’t do in the first place before releasing Linq-Sql or EF ? What was so much desperateness to release either of them for temporary basis and then release the second one as well?
Clearly I think there is some lack of coordination between teams. While I always thought Linq-To-SQL was not ready for large scale development, I am just worried that what other recently released products have similar fate?
Please note that first time comments go through approval so there will be some delay if you respond. Unless the post is flame-bait, abusive or libellous it will turn up — I’m just out enjoying Halloween in Seattle tonight ;-)