Filtering decides which items survive. Projection decides what shape they come out in.

Filtering with Where narrows a sequence down — but the items that survive still look exactly like they did going in. Very often that's not what you actually want to hand back to a caller. An API shouldn't return your internal Employee entity, salary and all, to a public endpoint. A report doesn't need the full Order object — just the customer name and total. Projection is how LINQ reshapes each item into something new.

This lesson covers Select for one-to-one transformation, and SelectMany for flattening nested collections into a single sequence.

What Is It?

The Simple Explanation

Projection means transforming each item in a sequence into something else — a different type, a subset of its data, a computed value. Select does this one item at a time, one-in-one-out. SelectMany does it when each item produces its own sub-sequence, and you want all of those sub-sequences merged into one flat result.

The Technical Definition

Select is generic over two type parameters — the input type TSource and a completely independent output type TResult. That's the essential difference from Where: Where always returns IEnumerable<TSource> (same type in, same type out); Select can return an entirely different shape. SelectMany's selector returns an IEnumerable<TResult> per item, and the method flattens all of those inner sequences into one single, flat IEnumerable<TResult>.

Why Does It Exist?

Without a dedicated transform operator, reshaping data means an accumulator and a manual loop — the same pattern you've now seen (and moved past) several times:

The "entity to DTO" transformation shown above is one of the single most common uses of LINQ in real applications — every API layer that shouldn't expose its internal domain models directly does exactly this. SelectMany solves a related but distinct problem: what happens when each item doesn't map to one output value, but to a whole collection of them — like each order having multiple line items, and you want a flat list of every line item across every order?

Big Picture

How It Works

Simple Example

SelectMany — Flattening Nested Collections

Code → Meaning → Result: Select alone would give you three lists inside one outer sequence — technically correct, but not what you usually want when you're asking "every item ordered, across every order." SelectMany collapses that nesting into a single flat list of six strings.

There's also an overload of SelectMany that lets you keep a reference to the outer item alongside each flattened inner item — useful when you need both:

Real-World Example

A web API exposes a product catalog endpoint. The internal Product entity carries fields (a database primary key, an internal supplier reference) that should never reach a public client. Projecting to a DTO at the API boundary is the standard, idiomatic pattern:

Note that Id (internal database key) and SupplierCode (internal-only field) never make it into ProductApiResponse at all — Select is the tool doing that boundary-shaping work, and this exact pattern shows up at nearly every API layer in real .NET applications.

Analogy

Under the Hood

public static IEnumerable<TResult> SelectMany<TSource, TResult>(
    this IEnumerable<TSource> source,
    Func<TSource, IEnumerable<TResult>> selector)
{
    foreach (var outerItem in source)
    {
        foreach (var innerItem in selector(outerItem))
        {
            yield return innerItem;
        }
    }
}

Like Where, both Select and SelectMany are yield return iterators — nothing runs until enumerated, and each output item is produced lazily, one at a time, as the consuming code asks for it.

Common Confusion

1. "Select filters too" — no, it never removes items

Select always produces exactly as many output items as input items — one-to-one, always. If you need fewer items and a different shape, that's Where followed by Select, not Select alone.

2. Select returning a list of lists vs SelectMany flattening them

The single most common mistake when working with nested data is reaching for Select when you actually want a flat result. If your projection's lambda itself returns a collection (o => o.LineItems) and you want every item from every inner collection merged into one sequence, you want SelectMany, not Select.

Common Mistakes

Mistake 1 — Using Select when you meant SelectMany

orders.Select(o => o.LineItems) gives you an IEnumerable<List<string>> — a sequence of lists, one per order — not the flat list of every line item you probably wanted. Use SelectMany whenever your projection returns a collection you want merged, not nested.

Mistake 2 — Projecting before filtering, doing extra unnecessary work

products.Select(p => new ProductDto(p.Name, p.Price)).Where(d => d.Price > 50) constructs a DTO for every product, including ones that will immediately be filtered out. Filter first, then project: products.Where(p => p.Price > 50).Select(p => new ProductDto(p.Name, p.Price)) — fewer objects allocated, same result. This ordering matters and is covered again in the LINQ Performance lesson at the end of this module.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You've learned how to reshape data with Select and flatten it with SelectMany. Let's check your understanding.

You can now filter and reshape sequences confidently. Next up: putting results into a meaningful order with OrderBy and friends.

dotnetmadeeasy.com — Learn C# and .NET, the right way.