drawbacks of linq

Question

What are the drawbacks of linq in general.

Answer 1

• Can be hard to understand when you first start out with it
• Deferred execution can separate errors from their causes (in terms of time)
• Out-of-process LINQ (e.g. LINQ to SQL) will always be a somewhat leaky abstraction - you need to know what works and what doesn't, essentially

I still love LINQ massively though :)

EDIT: Having written this short list, I remembered that I've got an answer to a very similar question...

Answer 2

Actually I can´t think of any drawbacks. It makes programming life a lot simpler because a lot of things can be written in a more compact but still better readable way.

But having said this, I must also agree with Jon that you should have some idea what you´re doing (but that holds for all technological advances).

Answer 3

the only drawback which it has is its performance see this article

Answer 4

Like any abstraction in programming, it is vulnerable to a misunderstanding: "If I just understand this abstraction, I don't need to understand what's happening under the covers."

The truth is, if you do understand what's happening under the covers, you'll get much better value out of the abstraction, because you'll understand where it ceases to be applicable, so you'll be able to apply it with greater confidence of success where it is appropriate.

This is true of all abstractions, and applies to Linq in bucketfuls. To understand Linq to Objects, the best thing to do is to learn how to write Select, Where, Aggregate, etc. in C# with yield return. And then figure out how yield return replaces a lot of hand-written code by writing it all with classes. Then you'll be able to use it with an appreciation of the effort it is saving you, and it will no longer seem like magic, so you'll understand the limitations.

Same for the variants of Linq where the predicates are captured as expressions and transported off to another environment to be executed. You have to understand how it works in order to safely use it.

So the number 1 drawback of Linq is: the simple examples look deceptively short and simple. The problem is, how did the author of the sample know what to write? Because they knew how to write it all out in long form, and they knew how pieces of Linq could be used as abreviations, and so they arrived at the nice short version.

As I say, not really specific to Linq, but highly relevant to it anyway.

Answer 5

The biggest pain with LINQ is that (with database backends) you can't use it over a repository interface without it being a leaky abstraction.

LINQ is fantastic within a layer (especially the DAL etc), but since different providers support different things, you can't rely on Expression<Func<...>> or IQueryable<T> features working the same for different implementations.

As examples, between LINQ-to-SQL and Entity Framework:

• EF doesn't support Single()
• EF will error if you Skip/Take/First without an explicit OrderBy
• EF doesn't support UDFs

etc. The LINQ provider for ADO.NET Data Services supports different combinations. This makes mocking and other abstractions unsafe.

But: for in-memory (LINQ-to-Objects), or in a single layer/implementation... fantastic.

Some more thoughts here: Pragmatic LINQ.

Answer 6

Anonymous types. Proper ORM should always return objects of 'your' type (partial class, with possiblity of adding my methods, overriding etc.). There are doezne of tutorials and examples of different complex queries using linq but non of them care to explain the advantage of returning a 'bag of properties' (return new { .........} ). How am I supposed to work with anonymous type, wrap it in another class again?