Should I worry about the upgrade path for LINQ (the query language)

Question

I'm starting to use LINQ as a true query language in code to help improve readability. Until recently I was afraid to touch LINQ because of the LINQ to SQL team move under the Entity Framework team (trying to ignore that conversation here) -- will LINQ the query language be a safe bet going forward (as much as anything in this fast moving industry) ?

Answer 1

It's worth distinguishing between "LINQ" and "a particular LINQ provider". I think it's safe to say that LINQ itself is here to stay - and it's phenomenally useful for in-process collection processing via LINQ to Objects.

As for which LINQ provider will "win" (if any) - that's a harder bet to call.

I would certainly learn the fundamentals of LINQ itself though - and LINQ to XML is a lovely XML API as well.

Answer 2

As Jon said it's very important to distinguish between LINQ providers. For instance

• LINQ to objects: This is based off of IEnumerable<T> and is so ingrained into the BCL that I find it very hard this is going anywhere
• LINQ to SQL: I don't use this nearly as much as I do LINQ but I know it has a good following and people seem to like it.

Caveat: I worked on LINQ so I'm pretty biased here.

What's really neat about LINQ, at what I think we really got right, is that anyone can write a LINQ provider. All that's needed is a few bindable methods of the right name and suddenly you have query syntax.

var query = from it in someCollection select it.SomeProperty;

I can write this statement without using any of the 3.5 framework. I have my own LINQ Provider which works against the 2.0 framework and is compatible with the query syntax used in the compiler.

I personally lean more towards the lambda/ extension method synatx but the resulting code is really no different.