Why should you care?

ShopNest code reads order.Customer.Email instead of manual join keys — navigations express business relationships in C#.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

var emails = await _context.Orders
    .Where(o => o.OrderDate >= DateTime.UtcNow.AddDays(-7))
    .Select(o => new
    {
        o.Id,
        Email = o.Customer!.Email,
        Lines = o.Items.Count
    })
    .ToListAsync();

What happened?

• o.Customer.Email translates to JOIN Customers on CustomerId.
• Items.Count becomes subquery or join COUNT — EF picks SQL shape.

Practice next

1. Define FK scalar + navigation on both ends when possible.
2. Use null-forgiving or required keyword for non-nullable navigations.
3. Prefer Select through navigations over Include when shaping DTOs.
4. Make Customer navigation optional on Order for guest checkout modeling.
5. Navigate Product.Category.Name in filter without Include.

Remember

Navigations represent relationships in C#. Pair with FK properties for clarity. Use in Select for typed joins.

ShopNest weekly order digest

Job projects customer email via Order.Customer navigation in one LINQ query.

Outcome: Clean C# expressing business path Customer ← Order.