Reason not to use LINQ

Question

Are there any good Reasons not to use LINQ in my projcts? We use .Net 3.5 and VSTO 3.0.

for the voters to close this question: imho it is a valid question, so why close it? — Razzie, Oct 16 '09 at 07:54
This is just highly argumentative since the use of LINQ is most of all a personal preference, just like several other subjects. Why use Windows? Why use c#? Why use Java? Why use PC's? This is a topic that can easily lead to heated discussions with no value. — Wim ten Brink, Oct 16 '09 at 07:59
Well, it's a shame that crauscher uses the words 'reason not to' (I edited it to a less subjective 'disadvantages of' but he doesn't like that :P) but underneath there's a valid question. I'd compare it more to a question like 'what's the disadvantage of using an ORM / Lucene / Remoting' etcetera. — Razzie, Oct 16 '09 at 08:06
Linq (language integrated query, iirc) is just the nicer syntax (from T in X select T) for some extension methods (which just happens to be in a Linq namespace). Is your question refering to the syntax vs extension methods, or to the whole Linq-package (including anonymous types)? — sisve, Oct 16 '09 at 08:10
Please have a look at [this topic](http://stackoverflow.com/questions/215548/whats-the-hardest-or-most-misunderstood-aspect-of-linq) : it may help you to have an answer. — Larry, Oct 16 '09 at 07:53

James · Accepted Answer · 2014-07-20T12:14:51.920

19

Personally I can't see why you wouldn't want to use it, it makes code much more readable.

With that being said, LINQ can sometimes be detrimental to performance in certain scenarios, that would really only be my reason for not using it.

edited Jul 20 '14 at 12:14

answered Oct 16 '09 at 07:51

James

80,725
18
167
237

@m.edmondson your article is a *lambda* expression not LINQ. I take your point though it's always good to try maintain readability, however, if I have code that's readable and takes 5 seconds vs code that takes 0.5 seconds and not so readable I would opt to using the more efficient code. You can make complex code just as readable by putting into functions or commenting. – James Sep 03 '12 at 08:25
Thanks for that, I've modified my article with an update to point out your point about lambda/LINQ – m.edmondson Sep 04 '12 at 22:25
@m.edmondson I guess the one thing I would say is although they aren't interchangeable, they are each others equivalent (they will both compile down to the exact same IL). It just depends on how you prefer to write your queries, some are easier to read using LINQ, some are easier using Lambda (or more succinct). – James Sep 05 '12 at 08:15
Thats true, I've been reading [John Skeet's article about this](http://msmvps.com/blogs/jon_skeet/archive/2011/01/28/reimplementing-linq-to-objects-part-41-how-query-expressions-work.aspx) – m.edmondson Sep 05 '12 at 13:02
1

I'm an oddball but I find it easier to read non linq expressions – rollsch Oct 21 '16 at 09:23

John Saunders · Answer 2 · 2015-01-05T14:09:04.333

The other answers have implied this, but here it is explicitly:

The term "LINQ" can refer to the overall set of technologies for Language INtegrated Query. These technologies permit a LINQ Query to be turned into an expression tree. That tree can be executed at a later time, by a "LINQ Provider".

The LINQ Provider looks at the expression tree and converts it into, for instance, SQL statements, or XML DOM navigation, or navigation through an object graph. These providers have names like "LINQ to SQL", "LINQ to Entities", "LINQ to Objects", etc.

There could be reasons to not use a specific provider.

Many of the individual LINQ providers come with additional tooling (some would say, "baggage"). This tooling helps provide some of the most common "pros and cons" about LINQ.

In particular, LINQ to SQL provides a direct, one to one mapping to the database schema. Each LINQ class corresponds to a single database table. If the structure of the database changes, then so does the code. This can be mitigated to an extent by using views.

I believe that LINQ to SQL is limited to Microsoft SQL Server. Also, Microsoft has stated that LINQ to SQL will not be a priority investment going forward.

LINQ to Entities is part of the ADO.NET Entity Framework (EF). EF provides for modeling your entities in a more abstract, conceptual level. For instance, you might have a Person entity that takes data from two tables that have a one to one mapping. Code accessing this entity need not care how the tables are broken out in the database.

I believe that LINQ to Entities is meant to work with many ADO.NET providers, not just SQL Server. Also, this is where Microsoft says it will be placing its investments going forward.

In both of these cases of LINQ to "some database", it's almost always going to be the case that a experienced SQL developer and/or DBA can write better queries than will be generated by LINQ. If performance is the top requirement, I believe that LINQ to Entities can map stored procedures into methods on the entities.

The big benefit of these LINQ providers is that you don't need that experienced SQL developer or DBA when you're working in an environment where performance is not the top priority. This frees them up to optimize queries that actually require their expertise.

Another reason not to use these directly is if you have security considerations preventing your users from having SELECT permissions to the database tables. In that case, use views or stored procedures.

The closest possible explanation and answer for the question that someone should be looking at. As it implies "Language INtegrated Query". +1 — gmaran23, Mar 13 '13 at 15:31

score 3 · Answer 3 · answered Oct 17 '09 at 02:26

Yes, there are reasons. I'm going to talk about some of the difficulties I've faced when using various LINQ providers for RDBMS.

LINQ works great in most cases, but when you want to build complex queries (e.g. in reporting apps) it's statically-typed nature becomes a disadvantage. It's hard to, for instance, conditionally JOIN, or conditionally GROUP BY, because the result type changes, even if in the end you want to project the same fields. It's also hard to do LEFT JOIN. If you really appreciate dynamic queries then SQL and ESQL are better options.

Also, the same LINQ query can be (and usually is) interpreted differently depending on the provider, which can lead to unexpected results when switching providers.

About SQL functions, not all the functions you need are mapped to CLR methods, and not all providers offer a extensibility mechanism for mapping functions.

Finally, the performance issue. Converting expression trees to store queries can be expensive, and sometimes the end result is not the best possible query. The most elegant source code is not always the best runtime code.

score 2 · Answer 4 · answered Oct 16 '09 at 08:18

The only reason would be if you have a very performance critical app as LINQ to Objects queries usually perform worse than for loops. This will change with .Net 4.0, when you can make use of PLINQ's parallel processing features.

Anyhow, if you have such a performance critical app, you probably should not use a managed environment anyways. in 99% of all cases LINQ will make your code more readable and more elegant. It's deferred execution mechanism may even gain you some performance under the right circumstances.

score 1 · Answer 5 · answered Oct 16 '09 at 07:52

Well, if you want to make a step backwards and work 2xtimes longer on your projects you shouldn't use it ;-)

I think there is no real good reason to NOT use it. You are faster, smarter and you can make less mistakes and have more control since you can work "datatyped"

score 1 · Answer 6 · answered Oct 16 '09 at 07:53

In a very short answer: no, there is no reason not to use Linq. Although it can be slightly hard to grasp for people new to the concept of functional programming (but only slightly), once you get the hang of it, you will love it, and it can in general greatly improve the readability of the code.

score 1 · Answer 7 · answered Oct 16 '09 at 08:14

1

It depends on whether you're referring to LINQ to SQL or LINQ as a modelling tool. Personally I use LINQ for modelling only because my superiors who are actually less educated than me in this area refuse to it for a number of reasons. One reason is that they've stopped adding new features completely and are only maintaining bug fixes in LINQ now. Secondly is that it's supposedly slower than direct SQL, which to a certain degree is true when running lower end hardware perhaps, I don't know. Thirdly is a domain perspective, if you want to shy away from SQL injection vulnerabilities supposedly it's wise to use stored procedures instead. In all instances for us, we use LINQ for modelling only now, stored procedures are "compiled" on the server after being run for the first time.

Personally I just meet requirements, I have no powers for decision, but LINQ is great for modelling and includes many handy features.

answered Oct 16 '09 at 08:14

Kieran Senior

17,960
26
94
138

2

You don't have to use stored procedures to avoid SQL injection, using sql parameters should be enough to protect from this. – James Oct 16 '09 at 08:17
Such as using {0} for paramaterized queries? – Kieran Senior Oct 16 '09 at 08:22
2

no like "SELECT * FROM ATable WHERE AField=@value" and using an SQL Parameter to define @value. – James Oct 16 '09 at 08:25
So doing `myDataContext.ExecuteQuery("SELECT * FROM tbl WHERE field = {0}", id);` is bad? How, in the context of `DataContext`, can you use parameterized queries as you've defined? – Kieran Senior Oct 16 '09 at 08:31
1

No its not bad, this is essentially what LINQ does behind the scenes anyways. I wasn't refering to using LINQ I was refering to using direct SQL with SQL command. – James Oct 16 '09 at 08:39
Ah okay, that's handy to know, I wasn't aware at all and was wanting to know about that. – Kieran Senior Oct 16 '09 at 09:07
Oh also, have you got a reference specifically to SQL injection and the use of queries in the context that I gave? I need it for an evidence report at work ;) – Kieran Senior Oct 16 '09 at 09:08
1

Well in the context you have, as I said before, this is essentially what LINQ is generating in the background. This article might help you http://thedatafarm.com/blog/data-access/linq-to-entities-entity-sql-parameterized-store-queries-and-sql-injection/ – James Oct 16 '09 at 09:32

score 1 · Answer 8 · answered Oct 16 '09 at 08:22

1

The LINQ architecture is good - but some may prefer to read source code that does not use the LINQ SQL-like syntax. So if you're strict on readability, you may want not to use that syntax.

answered Oct 16 '09 at 08:22

Lars D

8,483
7
34
37

2

Readability is not that big issue. – crauscher Oct 16 '09 at 08:23

score 1 · Answer 9 · answered Oct 22 '10 at 05:38

I have encountered some issues with it that I've had to work around. For example, depending on how your database relations are setup you may find that linq2sql works great for querying, but has trouble updating correctly. This happened to me and what I did was setup two sets of linq objects. The first had all the relationships I needed so I could use simpler syntax for querying, but the second didn't contain the relationships for when I wanted to update since I didn't need them then.

Performance shouldn't be a reason not to use it because generally that's only an issue for certain processes. And it's not like you have to use linq exclusively or not at all. I think a lot of people think "oh, direct sql is faster and there are some things I need to do that HAVE to be fast so I can't use linq". That's just silly though. Use it where you can, and use direct sql where you can't.

score 1 · Answer 10 · edited Nov 30 '12 at 15:10

What I can figure out from various posts is that it depends on requirement

LINQ works independent of datasource ....work on file objects and database in same way
LINQ can reduce multiple queries into one
LINQ has the type safety
Overall good to use and faster development
LINQ still has a lot of open issues
LINQ has stopped evolving (nothing new coming up)
SQL is more reliable and more efficent
SQL is better when working with more complex queries, stored procedures
SQL is faster then LINQ-SQL

So depending on if your project requires inline queries not so complex and involves to query data sources other then relational database like SQL use LINQ otherwise go for good old SQL server.....:)

score 0 · Answer 11 · answered Oct 16 '09 at 08:25

0

not to use LINQ if you mean LINQ as "LINQ to SQL" and your SQL Server has performance problem with a Adhoc Query Execution.

answered Oct 16 '09 at 08:25

kazuk

114
4

score 0 · Answer 12 · answered Feb 21 '11 at 15:45

0

As for me - only one reason not to use LINQ. It is third-party enhancement tools for this product. I prefer - Devart LinqConnect, for example.

answered Feb 21 '11 at 15:45

JackD

597
4
7

score -1 · Answer 13 · answered May 04 '12 at 13:36

-1

LINQ is a great technology, but produce a uggly code. If you thinking, you are a Picasso of code don't use it.

Produce code without LINQ is producing readable code. But i use always ;)

answered May 04 '12 at 13:36

pedrofernandes

16,354
10
36
43

I also agree but it seems most others do not. I wonder why this is, perhaps comiing from a C or ASM background vs coming from a Database background is the reason – rollsch Oct 21 '16 at 09:24

score -4 · Answer 14 · answered Oct 16 '09 at 07:54

-4

Yes, definitely makes things more readable and concise. Certainly did for the 15 years I used it in Visual FoxPro ;)

answered Oct 16 '09 at 07:54

Alan B

162
2

2

LINQ has been around that long? – Kieran Senior Oct 16 '09 at 08:09
From the wikipedia entry "_LINQ was released as a part of .NET Framework 3.5 on November 19, 2007._". Link here: http://en.wikipedia.org/wiki/Language_Integrated_Query – Kieran Senior Oct 16 '09 at 08:33
1

I think this answer is meant to (somewhat humorously) point to the fact that VFP had LINQ-ish functionality, with in-memory cursors and SQL support directly in the language, for years. – Eyvind Oct 16 '09 at 12:30

Reason not to use LINQ

14 Answers14

Linked