Feature Request: Extension support for included navigation properties

[Alerinos]

🚀 Feature Request: Extension support for included navigation properties

Description

Currently, the .Extension() method works well for root-level models in the repository chain, enabling external data sources (like REST APIs) to populate or enrich entity properties on-demand.
However, there is no support for applying extensions to related entities loaded via .Include().

Example (current behavior):

var organization = await repository
    .Include(x => x.Teams)
    .Include(x => x.Field)
    .Where(x => x.Id == organizationId)
    .GetFirstAsync<OrganizationDto?>();

In the example above, Teams and Field are included successfully. However, if these related entities need to be populated using an extension (e.g., fetching from an external source), there is no current way to apply .Extension() on them.

Proposal

Introduce a mechanism to define and execute extensions on included navigation properties, similar to how .Extension() currently works on the root entity.

Possible Syntax Idea:

.Include(x => x.Teams)
.ExtensionFrom(x => x.Teams, x => x.TeamExtension)

This could signal to the repository that the TeamExtension logic should be executed for each Team entity inside the Teams collection.

Use Case

Let’s say Team entities are partially stored in the database, but their full data (e.g., latest stats) comes from an API. Using an extension would allow lazy/explicit enrichment. This works fine for top-level queries but breaks down once the Team is loaded via .Include.

Benefits

• Consistent API and design across all entity levels
• Keeps extension logic centralized and pluggable
• Enables richer, API-driven data structures in aggregate queries

Suggested Tasks

• Define a strategy for registering extensions for navigation properties
• Extend repository logic to resolve and apply extensions after Include
• Consider support for collections and single navigation props
• Ensure compatibility with async and cancellation patterns