Pros and Cons of LINQ (Language-Integrated Query)

Question

• What are the pros and cons of LINQ (Language-Integrated Query)?
• What are the best and worst cases in which to use LINQ?
• How have you benefitted or not benefitted from using LINQ?
• Which data sources benefit the least and the most from LINQ?

Answer 1

I'm a massive fan of LINQ - although it needs to be kept in perspective, and not treated as a silver bullet.

Pros:

• Declarative approach makes queries easier to understand and more compact
• Extensibility and expression trees allow mostly consistent querying of multiple sources
• Even in-process queries can be implemented in ways other than LINQ to Objects - e.g. Parallel LINQ and my own Push LINQ framework. Very flexible.
• Fabulously useful for in-process queries, where it's easiest to understand
• Great to be able to avoid SQL in strings etc
• Wide range of operators provided by default, and others can easily be added for LINQ to Objects
• Language features introduced primarily for LINQ are widely applicable elsewhere (yay for lambdas)

Cons:

• Query expressions aren't understood well enough, and are overused. Often simple method invocation is shorter and simpler.
• Inevitable inconsistencies between provider - impedance mismatch is still present, which is reasonable but needs to be understood
• There will always be some things you can do in SQL but not in LINQ
• Without understanding what's going on, it's easy to write very inefficient code
• It's hard to write a LINQ provider. This may well be inevitable, but more guidance from Microsoft would be appreciated.
• It's a new way of thinking about data access for most developers, and will need time for understanding to percolate
• Not specifically LINQ but related to it - the way extension methods are discovered in C# isn't granular enough
• Some operators are "missing", particularly the equivalents of OrderBy for things other than ordering - e.g. finding the item with the maximum value of a property
• Deferred execution and streaming are poorly understood (but improving)
• Debugging can be very tricky due to deferred execution and streaming

I find it's best when dealing with in-process queries. They're easy to predict, understand and extend. Complementary technologies like LINQ to XML and Parallel LINQ are great. LINQ to Objects can be used almost anywhere.

LINQ to SQL etc are really nice where they're appropriate, but they're harder to understand and need more expertise. They're also only applicable in certain areas of your code.

Answer 2

My favorite part: using them to simplify writing unit tests. Also IEnumerable chains have urged me to write more fluent interfaces in my code.

Cons: Lambdas and extension methods are my hammers and all problems are nails.

Overall: breathed new life into programming in C# for me.

Answer 3

There is a problem with them of sneaking exceptions out of try catch blocks by way of delayed execution.

for example:

var l = new List<int>() {1, 2, 3};
try
{
    l.Select(x => x / 0);
}
catch
{
    // error
}

l.elementAt(0); // exception occurs here outside of the try catch

Which can be tricky the first time you run into it, especially as the debugger will point you at the code inside the try-catch.

Otherwise I find them incredibly useful and very time saving.

Answer 4

I've used LINQ mainly to work on collection of objects. LINQ works wonderfully with object collections, removing the need of predicate functions in most cases.

I tried using LINQ to SQL a little while ago, but found it underpowered and clumsy. In particular I couldn't bring myself to use the SQL Database class designer. Maybe it does give intellisense on the database, but who needs it when you've got SQL?

Let me tell you though, it's certainly a good idea to learn more about LINQ, as the applications in the future should only increase.

Answer 5

Pro:

• LINQ to SQL allows for RAD with database very nicely
• It is easy to query multiple data sources
• LINQ to SharePoint, LINQ to Active Directory, LINQ to TFS, LINQ to Umbraco, (and the list goes on)

Con:

• Like any new technology too many people don't understand it but still use it

@Jon Skeet - another great response, you steal everyones thunder :P. I totally agree about how hard writing a provider is, I'm in the process of it at the moment! Are you familiar with Bart De Smet? He's got lot of good examples of doing so.