LINQ in C#: Querying Collections

LINQ (Language Integrated Query) gives you one vocabulary for filtering, shaping and summarizing data, whether it lives in a , an XML document, or a database table queried through Entity Framework Core.

The everyday operators

Operator	Purpose
	keep items that match a condition
	transform each item
,	sort (add for reverse order)
	split into groups by a key
,	does at least one / does every item match?
, ,	pick one item
, , , ,	summarize
,	paging
	remove duplicates

Grouping

Queries are lazy (deferred execution)

A LINQ query is a recipe, not a result. Nothing runs until you enumerate it with , , , and so on.

This is powerful, but it has two consequences:

1. The query reflects the data at the moment you run it, not when you wrote it.
2. Enumerating the same query twice runs it twice. With EF Core, that means two database round trips. If you need the results more than once, call once and reuse the list.

Choosing between First, FirstOrDefault and Single

• throws if there are no items.
• returns (or the default value) if there are none.
• throws unless there is exactly one item. Use it when more than one match would be a bug, such as looking up by a unique id.

IEnumerable versus IQueryable

On an in-memory collection, LINQ runs as ordinary C# code. On an EF Core , the same operators are translated into SQL and executed by the database. The catch: once you convert to (for example by calling or ), the remaining operators run in memory.

Common mistakes

• Calling when says the same thing and stops at the first match.
• Modifying a collection while a query over it is being enumerated.
• Calling too early, which pulls extra data into memory.
• Putting a method that EF Core cannot translate to SQL inside a . It fails at run time, so test the query.