Most powerful and unexpected benefit of Linq in .NET OOP/D?

Question

Since learning about Linq and gaining experience in it, I find myself leaning on it more and more. It’s changing how I think about my classes. Some of these changes were expected (ex. Using collections more) but often unexpected (ex. Getting initial data for a class as an XElement and sometimes just keeping it there, processing it lazily.)

What is the most powerful and unexpected benefit of Linq to .NET OOP/D? I am thinking of Linq-to-objects and Linq-to-xml in particular, but include Linq-to-Entities/SQL too in so far as it has changed your class strategy.

Answer 1

I've noticed a couple of significant benefits from using LINQ:

• Maintainability - it's much easier to understand what code does when you read a semantic transformation using LINQ, rather than some confusing looping constructs hand-written by a developer.

• Performance - Because of LINQ's deferred and streaming execution, you often end up with code that performs better - either by distributing the workload, or allowing unnecessary transformations to be avoided (particularly when only a subset of results are consumed). In the future, as multicore processing becomes more significant, I expect that many LINQ methods may evolve to support native parallel processing (think multi-core sort) - which should help keep .NET applications scalable in the multi-code future.

There are a couple of other nice benefits:

• Awareness of Iterator Generators: Once developers learn about LINQ, some of them go on to learn about how it works. This helps to generate awareness of the yield return syntax in C# - which is a powerful way of writing concise and correct sequence iterators.

• Focus on business problems: LINQ frees developers to focus on solving the underlying business problems, rather than trying to optimize loops and algorithms to run in the fewest cycles, or use the least number of lines of code. This goes beyond just the productivity of having a library of powerful sequence transformation routines.

Answer 2

I feel the code is easier to maintain and easier to Test compared to have a solution in SQL stored procedures.

Combining LINQ with extensions I get something like (should maybe use some kind of Fluent Interface.....)

  return source.Growth().ShareOfChangeDate();

where Growth and ShareOfChageDate are extensions that I easily can do unit tests on

and as LBushkin says the line above I can present for the customer when we discuss

Issues I feel i get less controll on the SQL generated and it is a littlebit magic to find performance problems.....