LINQ to SQL next steps
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.
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 runtime elements need to stick to the .NET Framework schedule.
(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.