Somebody mentioned that LINQ is a declarative style of programming. I just wanted to expand on that.
One way I use LINQ is to write test oracle code. It's very important that the test code be simple and as close to "obviously correct" as possible, or else it will end up with as many bugs as the code that it's supposed to test. With one particular feature that I'm testing now, I wrote out a small list of set comprehensions that describe exactly how I expect the feature to work. Thanks to LINQ, converting those comprehensions to code becomes trivially easy:
A = all items
B = [x in A: x.Type = selectedtype, x.Source = "sourceA"]
C = [x in A: x.Source = "sourceB"]
D = B union C
In code:
IEnumerable SetB(IEnumerable allItems, MyType type)
{
var result = from item in allItems
where item.Type == type && item.Source == "sourceA"
select item;
return result;
}
IEnumerable SetC(IEnumerable allItems)
{
var result = from item in allItems
where item.Source == "sourceB"
select item;
return result;
}
IEnumerable SetD(IEnumerable allItems, MyType type)
{
var setB = SetB(allItems, type);
var setC = SetC(allItems);
return setB.Union(setC);
}
While still quite a bit more verbose than the mathematical expressions, it's much simpler and easier to call "obviously correct" than imperative code would be. The LINQ code is declarative like the math is declarative. Less translation, closer to the spec. LINQ, when used appropriately, is pretty much a "Do what I mean" language.
Note that I wouldn't write the actual code this way. Performance is not a requirement for test code, but it is for the real code, so the real code still needs to be a SQL stored procedure.
