LINQ

What it is and why it exists

LINQ stands for Language Integrated Query. It supplies common query patterns for filtering, transforming, joining, grouping, and summarizing data with static type checking. Each query step remains an ordinary expression, so the compiler can check property names, lambda parameter types, and result types.

LINQ to Objects is the form you meet most often. Extension methods on System.Linq.Enumerable accept IEnumerable<T> and use delegates to process arrays, lists, and other enumerable sources in the current process. Where retains matching elements, Select changes each element’s shape, OrderBy establishes order, and GroupBy forms groups by key.

LINQ can also describe remote queries. Operators on System.Linq.Queryable accept expression trees, which an IQueryable<T> query provider interprets or translates. A database is only one possible source; the specific provider defines the available operations and execution semantics.

LINQ solves query composition, not the problem of squeezing every loop onto one line. Short, side-effect-free data transformations usually fit a pipeline. An ordinary loop is often clearer when the work includes complex state transitions, per-item error recovery, or several branches. Choose based on whether the behavior is clear, not on character count.

Query syntax and method syntax belong to the same LINQ model. Query syntax supplies clauses such as from, where, orderby, join, group, and select, which the compiler translates to method calls. Method syntax exposes every standard query operator directly, and the two forms can be combined in one expression.

How it works

A pipeline can store operations instead of results

Calling Where or Select usually gives you an object representing query steps, not a populated result collection. When code actually requests elements, the query pulls from its source and applies each operator in order. This is deferred execution: the caller composes a query first, then decides when and how much of the result to consume.

The flow below shows the pull relationship when a foreach first consumes a LINQ to Objects pipeline. Each request from the consumer makes the pipeline search upstream for the next matching value.

foreach, ToList, Count, First, and Sum all demand results, so they trigger the relevant query work. They consume differently: First can stop after finding an element, Count usually has to determine the whole result’s size, and ToList stores all results in a new list. Don’t mistake “triggers execution” for “always builds a collection.”

Streaming and buffering steps

Where and Select can process and yield one element at a time. Take can stop reading upstream once it reaches its limit, and Any can return when it finds its first match. Such operations support short-circuiting, though they still depend on whether upstream can produce values incrementally.

OrderBy must obtain all input before it knows the first sorted result. GroupBy also reads the source and builds groups. Both can remain deferred until enumeration starts, but they buffer after that point. “Deferred” and “streaming” are separate properties.

Materialization writes query results into a concrete container. It fixes that container’s membership and permits repeated reads without rerunning the upstream query, but it doesn’t recursively copy element objects. If the source and result refer to the same mutable object, both can still observe mutations to that object.

The compiler translates query syntax

A query expression must begin with from and end with select or group. The compiler translates its clauses into calls such as Where, Select, OrderBy, Join, or GroupJoin according to language rules. Query syntax isn’t a separate runtime query engine, and looking like SQL doesn’t make it execute remotely.

A let clause introduces a computed value for later clauses, while multiple ordering keys map to an initial ordering followed by subsequent ordering. Query syntax doesn’t cover every standard operator; common operators such as Take and Distinct are normally appended as method calls. Query syntax is often readable with several range variables or joins, while a method chain is compact for ordinary filtering and projection.

Generic types connect the steps

An IEnumerable<Product> still produces Product after Where. Select(product => product.Name) changes the element type to string, so the next step receives string. Anonymous types, records, and tuples can all serve as intermediate projections as long as they don’t cross API boundaries where those types are unsuitable.

The operator determines the target signature of a lambda. Enumerable.Where needs a Func<T, bool>, so its predicate must return a Boolean. A SelectMany selector returns a nested sequence, and the operator flattens those sequences into one result sequence. Compile-time type relationships prevent many shape errors, but they can’t tell whether a business predicate filters the wrong field.

Result cardinality is part of the contract

First says at least one element must exist but allows more; an empty result throws InvalidOperationException. Single requires exactly one and throws for either zero or multiple results. The OrDefault variants only turn “no element” into a default value; SingleOrDefault still rejects multiple elements.

The default can be valid data. When FirstOrDefault over IEnumerable<int> returns 0, the caller can’t tell from that value alone whether the first item is zero or there was no item. If the distinction belongs to the business contract, use a single-pass TryGet-style helper, project to a nullable value, or return a domain result that represents presence.

Aggregates also have individual empty-sequence rules. Count and integer Sum can return zero, while Average, Min, and Max throw on many non-nullable numeric sequences with no elements. Don’t infer boundary behavior from an operator’s name; put empty, single-item, and multi-item inputs in tests.

Enumerable and Queryable form an execution boundary

Enumerable operators accept delegates and execute ordinary .NET code. Queryable operators accept expression trees and hand the query description to a provider. The same lambda source can become a delegate or an expression tree depending on the receiver’s static type.

AsEnumerable doesn’t materialize data by itself. It binds subsequent extension calls to Enumerable, so later predicates run in the current process; ToList is what immediately enumerates and stores results. Calling either too early on a remote source has different effects, but both can change which work happens remotely.

A provider doesn’t have to support every legal C# expression. A delegate that runs correctly over an array doesn’t prove that the same structure translates to a target query language. Remote queries need verification against the real provider for translation, parameterization, null semantics, ordering, and round trips. List<T>.AsQueryable() proves only an in-memory path.

Examples

These four examples use inventory and order data to build from filtering and projection to deferred execution, flattening and grouping, and a query-syntax join. All were compiled and run with .NET SDK 10.0.400, and every output came from the actual process.

Filter, order, and project

The first pipeline keeps products that are in stock and cost at least 100m, orders them by descending price and then ascending name, and projects only the two fields needed for output.

Where leaves the element type unchanged, while Select projects Product into an anonymous type. ThenBy supplies a deterministic secondary order for equal prices. Calling another OrderBy instead would replace the previous primary ordering with a new one.

This query doesn’t execute until foreach. The loop only reads the results and performs no source mutation or external side effect, so its timing is clear. If a caller must see exactly the same members later, call ToArray or ToList at the agreed boundary.

Compare a deferred query with a materialized snapshot

This example defines a query and immediately takes an array snapshot, then changes the source list. Enumerating the original query again sees the new order, while the array retains its membership from materialization time.

using System;
using System.Collections.Generic;
using System.Linq;

var orders = new List<Order>
{
    new("A-100", 20m),
    new("B-200", 75m)
};

IEnumerable<string> largeOrderIds = orders
    .Where(order => order.Total >= 50m)
    .Select(order => order.Id);

string[] snapshot = largeOrderIds.ToArray();

Console.WriteLine($"snapshot: {string.Join(", ", snapshot)}");

orders.Add(new("C-300", 80m));

Console.WriteLine($"deferred: {string.Join(", ", largeOrderIds)}");
Console.WriteLine($"snapshot: {string.Join(", ", snapshot)}");

public sealed record Order(string Id, decimal Total);

snapshot: B-200
deferred: B-200, C-300
snapshot: B-200

The array fixes a set of element references; it isn’t a deep copy of the elements. Order is an immutable record here, so only the list addition creates a difference. With mutable elements, the snapshot and source could still observe changes to the same element object.

The query variable’s static type is IEnumerable<string>, which doesn’t promise that results already reside in memory. An API returning such a deferred query should state source ownership, whether enumeration is repeatable, and whether the source remains valid until consumption finishes.

Flatten with SelectMany, then group

Each order contains several lines. SelectMany retains the customer name while flattening, GroupBy applies an explicit case rule for SKUs, and the remaining steps calculate units and customers for each SKU.

using System;
using System.Linq;

Order[] orders =
[
    new("Ana",
    [
        new("BK-1", 2),
        new("PN-2", 3)
    ]),
    new("Bo",
    [
        new("bk-1", 1)
    ])
];

var totals = orders
    .SelectMany(
        order => order.Lines,
        (order, line) => new { order.Customer, line.Sku, line.Quantity })
    .GroupBy(row => row.Sku, StringComparer.OrdinalIgnoreCase)
    .Select(group => new
    {
        Sku = group.Key,
        Units = group.Sum(row => row.Quantity),
        Customers = string.Join("/", group
            .Select(row => row.Customer)
            .Distinct()
            .OrderBy(name => name))
    })
    .OrderBy(total => total.Sku, StringComparer.OrdinalIgnoreCase);

foreach (var total in totals)
{
    Console.WriteLine($"{total.Sku}: {total.Units} units ({total.Customers})");
}

public sealed record Order(string Customer, Line[] Lines);
public sealed record Line(string Sku, int Quantity);

BK-1: 3 units (Ana/Bo)
PN-2: 3 units (Ana)

The result selector places order context and line data in one row object, so flattening doesn’t lose the customer. A group retains the first encountered spelling as its Key, which is why the output shows "BK-1". Case-insensitive equality isn’t a display-normalization policy.

GroupBy reads its input and builds groups after enumeration begins. If input can be enormous or infinite, that buffering requirement changes which sources the API can accept. A Take after grouping doesn’t reduce the input that grouping must read.

Express a group join with query syntax

Query syntax makes the customer, order group, and subtotal easy to name together. A group join retains customers with no orders, and where then removes results whose total is too small.

using System;
using System.Globalization;
using System.Linq;

Customer[] customers =
[
    new(1, "Alice"),
    new(2, "Bob"),
    new(3, "Cara")
];

Order[] orders =
[
    new(101, 1, 40m),
    new(102, 1, 65m),
    new(103, 2, 30m)
];

var summaries =
    from customer in customers
    join order in orders on customer.Id equals order.CustomerId into customerOrders
    let total = customerOrders.Sum(order => order.Amount)
    where total >= 50m
    orderby total descending, customer.Name
    select new { customer.Name, Total = total };

foreach (var summary in summaries)
{
    string total = summary.Total.ToString("F2", CultureInfo.InvariantCulture);
    Console.WriteLine($"{summary.Name}: {total}");
}

public sealed record Customer(int Id, string Name);
public sealed record Order(int Id, int CustomerId, decimal Amount);

Alice: 105.00

The compiler translates join ... into to a group join and constructs suitable projections for let and the later clauses. Sum over an empty decimal sequence returns zero, so Cara is removed by where rather than failing during aggregation.

The sources here are arrays, so delegates execute in memory. If a range variable comes from IQueryable<T>, the same syntax binds to Queryable; you must then verify that the provider can translate the group join, aggregate, and ordering combination.

Pitfalls

Treating a query variable as a snapshot

Fix: decide whether callers need a live view or a stable snapshot. For a snapshot, materialize exactly once at an explicit boundary and say whether it is a container snapshot or a deep element copy. For a deferred query, keep the source valid through the entire consumption period.

Enumerating a source with work or side effects more than once

Fix: if the contract needs one stable result set, materialize once and use the collection’s Count and iterator. If the source deliberately represents a stream, design a single-pass consumer instead of probing for emptiness first. One enumeration can handle the first item and all following items.

Hiding a cardinality error with an element operator

Fix: choose First, Single, and their OrDefault variants from the domain constraint, then test zero, one, and multiple results separately. When a default value is valid data, don’t let one bare value represent both “missing” and a real result.

Losing primary order with a second OrderBy

Fix: use OrderBy or OrderByDescending for the first key, followed by ThenBy or ThenByDescending for later keys. Assert the full sequence with data that has equal primary keys and different secondary keys, plus different primary keys with equal secondary keys.

Mutating a source collection during enumeration

Fix: collect the intended changes separately, then apply them after enumeration, or use a collection’s dedicated bulk operation. If an algorithm truly needs mutation while reading, choose a data structure and traversal whose contract explicitly supports it.

Falling back to memory at a provider boundary

Fix: mark the IQueryable<T> to IEnumerable<T> boundary and keep translatable filters, projections, and limits before it. Inspect the generated query and results with the real provider. Rewrite untranslatable logic, or switch explicitly only after applying a well-defined data bound.

Further reading

• Microsoft Learn: LINQ overview
• Microsoft Learn: Query expression basics
• Microsoft Learn: Standard query operators
• Microsoft Learn: Deferred execution and lazy evaluation
• Microsoft Learn: IEnumerable<T> interface
• Microsoft Learn: IQueryable<T> interface