42

What are the fundamental misunderstandings people have when they first start using LINQ?

For instance, do they think it is one thing when it is really something else?

And, are there some best practices to employ to avoid these mistakes?

Even Mien
  • 44,393
  • 43
  • 115
  • 119

15 Answers15

114

That it should be used for everything.

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
  • Yeah, I definitely went through this phase. I like to think that I've managed to defeat the tendency now, though. :) Good thing for my employer that all my Linq abuse took place on my own time with personal projects! – Greg D Apr 22 '09 at 14:20
  • 1
    It's certainly important to recognise when it isn't the right approach. – Jeff Yates Apr 22 '09 at 14:21
  • 2
    I see lots of programmers who overuse implicitly typed local variables. – RichardOD Apr 30 '09 at 14:35
  • 3
    Can you give an example of when it shouldn't be used? I guess I'm still in the "use it whenever possible" stage. – Joe Chung Jul 03 '09 at 06:35
  • 1
    @JTA you can accomplish that by either unvoting and upvoting this answer again, or you can downvote all the rest of the answers to get the same effect :P – nawfal Nov 21 '12 at 14:16
  • 2
    It's super funny to try and do so however :P... Besides, it's much easier to say "Just use linq" when a co-worker asks a question rather than coming up with an actual answer... Just try it, ill promise you it will work... :P... They won't ask another question for hours, probably mostly because figuring out how to brew coffee using linq is after all a difficult task ;)... – Jens May 01 '14 at 12:37
  • This answer and improper understanding of delayed execution... still a thing in 2019. – mhangan Oct 25 '19 at 15:20
32

Failing to understand the differences betweeen (or existence of!):

.First()
.FirstOrDefault()
.Single()
.SingleOrDefault()

Not understanding deferred execution.

Richard Ev
  • 52,939
  • 59
  • 191
  • 278
  • 6
    +1 for noting Single. I've been using First and commenting that "// There can be only one". – Greg D Apr 22 '09 at 14:39
  • 1
    Yeah- deferred execution got me when I first started to use LINQ. I had a unit test that was generating different test data when I expected it to be the same. – RichardOD Apr 30 '09 at 14:34
  • That deferred execution website was stuck in a half-loading state and I thought it was some clever joke until I reloaded the web page. – Mateen Ulhaq Jan 19 '16 at 21:31
25

That it only refers to LINQ to SQL

Scott Weinstein
  • 18,890
  • 14
  • 78
  • 115
18

The biggest mistake people make when using LINQ is the same as when people try to use any sort of technology that lies on top of a technology that they don't have any good grounding in.

If you can't understand proper/efficient DB querying, you will screw up with LINQ.

If you can't understand the basic fundamentals of ADO.NET and data access, you'll probably screw up.

People think that by using LINQ it will allow them to coast by, but it won't.

TheTXI
  • 37,429
  • 10
  • 86
  • 110
  • 2
    So true, people who don't even get the idea of a transaction often make the most stupid mistakes with LINQ (i.e. reusing a query because they don't get the lazy nature of IQueryable, hogging the DB server, too...) – em70 Apr 22 '09 at 17:01
  • 5
    @TheTXI Your answer demonstrates a classic LINQ mistake by assuming Linq = Linq TO SQL. Check out J. Skeets C# in Depth for more information. – Ash Jan 21 '10 at 17:16
7

Somethings which come to mind are

  • It must be slower, better use plain C#
  • Trying to use it where simple C# would be more readable/manageable
Niran
  • 1,106
  • 1
  • 8
  • 10
  • 4
    Both of these points are excellent. I recently saw a dozen or so lines of code preceded by a comment that it was done this way to improve performance. I ran a benchmark on it to show the author that a one-line LINQ statement actually ran faster than the optimized loop he had. – StriplingWarrior Jul 06 '10 at 19:28
7

One basic one that I see in LINQ to SQL is not understanding DataContext. It is a Unit of Work object and should be re-created for each unit of work.

Even Mien
  • 44,393
  • 43
  • 115
  • 119
4

Possibly, one of the misconceptions people might have is that the way a LINQ query is written, especially LINQ2SQL, has no impact on performance. One should always know what goes on in the background, if one intends to write code that has high performance, otherwise you might end up with interesting timeouts, OOMexceptions, stack overflow and such... =)

J. Steen
  • 15,470
  • 15
  • 56
  • 63
  • 2
    This is actually very much untrue. While LINQ2SQL likely won't suffer from this, LINQ to objects can be greatly affected by the ordering of query elements (for example, placing a where clause BEFORE a join can speed up the code considerably). – Adam Robinson Apr 22 '09 at 14:13
  • 1
    I've traced linq2sql queries and have had greatly differing results on how and in what order I write conditions and predicates. – J. Steen Apr 22 '09 at 14:15
  • 3
    Adam: That sounds like you're actually agreeing with the answer. It's a *misconception* that it has no impact on performance - in other words, it *can* have an effect on performance. – Jon Skeet Apr 22 '09 at 14:15
  • 1
    @Jon: I think Adam is disagreeing with the "especially LINQ2SQL" – Harper Shelby Apr 22 '09 at 14:17
  • @metaphor, what you wrote in your answer doesn't jive with your comment. – NotMe Apr 22 '09 at 14:19
  • 1
    D'oh. Looks like my reading comprehension needs some work. But thanks for the benefit of the doubt, Harper ;) – Adam Robinson Apr 22 '09 at 14:20
  • @Christ, it doesn't? I thought I said that LINQ2SQL suffers, and that my comment says I've determined this empirically. Hmm. "differing results" might make one thing I meant the actual query result. Dang. – J. Steen Apr 22 '09 at 14:21
  • @Chris! Not Christ. Yes. – J. Steen Apr 22 '09 at 14:21
4

Here is one, LINQ to SQL queries involving strings cause SQL Server procedure cache bloat People need to be aware of that

SQLMenace
  • 132,095
  • 25
  • 206
  • 225
3

LINQ as a language is pretty straight forward and not so unexpected, especially if you're familiar with functional programming.

The concept of Deferred Execution is probably the biggest gotcha, and one of the best features. When you use LINQ that returns an IQueryable it's important to remember you are NOT executing whatever code you just wrote. It isn't until you call one of the methods that produces some other result that the query is executed.

Also, in terms of the LINQ to SQL provider, the biggest gotcha I've found is the performance cost. Turns out there is significant CPU cost to constructing SQL queries that are incurred every time the LINQ query is ran, unless you pre-compile your highly trafficked queries.

JD Conley
  • 2,916
  • 1
  • 19
  • 17
3

I totally agree with Adam Robinson, in fact the BIG mistake is that people stops on the beauty syntax not going deeper in the tech-facts, in terms of impacts or architectural views.

Sometimes people think about it as one thing when it's really another thing.. about that it's important to note Linq is a "Technology" and could be implemented in many ways, each of them could impact in different way about performance and design (for example), the basic syntax remain the same but the underlying things could changes.

Actually, starting from the great and growing implementations, there's not a complete list of best practices, the best practices could begin from:

  1. understanding before what kind of implementation will be used (Linq2Sql, Linq2Objects, Linq2CSV, Linq2Excel, Linq2LDAP, Linq2JSON, Linq2Xml, Linq2Xsd and more)
  2. then trying to understand what the basic technology features are intended in the choosed implementation
Hoghweed
  • 1,938
  • 1
  • 16
  • 35
3

Speaking for myself, knowing when a sequence will be buffered or streamed is important.

Filling a buffer with large amounts of data will consume lots of memory. If possible, operations like reversing, counting, ordering, etc. should be done once the data has been reduced. In joins the left sequence is streamed and the right is buffered. When there's a significant difference in size, put the smaller one on the right.

Matthew Sposato
  • 1,635
  • 1
  • 11
  • 13
2

Using linq2sql on tables with no primary keys (and not defining one in the designer).

Specially if what they are doing is an update, it doesn't update anything and you get no error.

eglasius
  • 35,831
  • 5
  • 65
  • 110
2

A lot of people think that LINQ is 'Magical SQL' they can use in Code. It looks like SQL, but it's quite different. Understanding that it's difference and what it's really doing will prevent a lot of frustration.

Rob P.
  • 14,921
  • 14
  • 73
  • 109
1

Understanding where you go from Linq2SQL/Entities to Linq2Objects. Understanding what is and is-not being executed in the DB engine versus in your application. Knowing when you are working with in-memory objects versus the underlying Linq provider that you are using, and then knowing how to intentionally transition from Linq2SQL to Linq2Objects whenever you need to perform post-query processing leveraging C#/.NET functions not supported in your provider.

AaronLS
  • 37,329
  • 20
  • 143
  • 202
1

I think understanding the point of the query execution is often a mistake (i.e. believing it's at the point of the query rather than at the point the data is first accessed), along with the belief that just because it compiles that it's going to run.

This in reference to Linq to SQL.

A fantastic tool for Linq is LinqPad by Joe Albahari, allowed me to learn Linq so much more quickly. If you don't have it, get it! And I'm not even on commission ;)

Lazarus
  • 41,906
  • 4
  • 43
  • 54