不修改URI的前提下，能否扩展IQueryable添加未选中的OData额外属性？

Nice question! Your current approach of overriding ApplyQuery works, but I get why you’d want a cleaner, less implementation-dependent way. Let’s break down three better extension points you can use:

1. Modify the Select/Expand Options Before Applying the Query #

Instead of retrofitting properties after the base query runs, you can adjust the SelectExpandQueryOption upfront to include your extra properties. This way, the base OData query handling automatically includes them, aligning with standard OData behavior.

Here’s how to implement it:

public class EnableAdvancedQueryAttribute : EnableQueryAttribute
{
    private readonly List<string> _extraProperties = new List<string> { "ExtraProperty1", "ExtraProperty2" };

    public override IQueryable ApplyQuery(IQueryable queryable, ODataQueryOptions queryOptions)
    {
        if (queryOptions.SelectExpand != null)
        {
            var edmType = queryable.ElementType.GetEdmType();
            if (edmType is IEdmEntityType entityType)
            {
                foreach (var propName in _extraProperties)
                {
                    // Check if the property exists in the EDM model
                    var edmProperty = entityType.FindProperty(propName);
                    if (edmProperty == null) continue;

                    // Check if the property is already selected
                    var isAlreadySelected = queryOptions.SelectExpand.SelectExpandClause.SelectedItems
                        .OfType<PathSelectItem>()
                        .Any(item => item.Path.LastSegment is PropertySegment propSeg && propSeg.Property.Name == propName);

                    if (!isAlreadySelected)
                    {
                        // Add the extra property to the selected items
                        var pathItem = new PathSelectItem(new ODataPath(new PropertySegment(edmProperty)));
                        queryOptions.SelectExpand.SelectExpandClause.SelectedItems.Add(pathItem);
                    }
                }
            }
        }

        // Let the base OData logic handle the query with the updated select options
        return base.ApplyQuery(queryable, queryOptions);
    }
}

Pros: Integrates fully with OData’s query rules (works with $select, $expand, etc.), produces standard OData responses, and respects the EDM model.
Cons: Requires working with OData’s EDM type system, which adds a bit of boilerplate, but it’s far cleaner than modifying the IQueryable after the fact.

2. Use a Custom OData Serializer #

If you want to inject extra properties at the serialization stage (regardless of what the client requested in $select), a custom ODataEntityTypeSerializer is a great fit. This bypasses query-level changes and adds properties right before sending the response.

First, create the custom serializer:

public class CustomEntitySerializer : ODataEntityTypeSerializer
{
    public CustomEntitySerializer(ODataSerializerProvider provider) : base(provider) { }

    public override void WriteEntry(ODataWriter writer, ODataEntry entry, EntityInstanceContext context)
    {
        // Pull the extra properties from your entity instance
        var entity = context.EntityInstance;
        var extraProp1 = entity.GetType().GetProperty("ExtraProperty1")?.GetValue(entity);
        var extraProp2 = entity.GetType().GetProperty("ExtraProperty2")?.GetValue(entity);

        // Add them to the OData entry
        entry.Properties.Add(new ODataProperty { Name = "ExtraProperty1", Value = extraProp1 });
        entry.Properties.Add(new ODataProperty { Name = "ExtraProperty2", Value = extraProp2 });

        // Let the base serializer handle the rest
        base.WriteEntry(writer, entry, context);
    }
}

Then register it with a custom serializer provider:

public class CustomSerializerProvider : DefaultODataSerializerProvider
{
    private readonly CustomEntitySerializer _customEntitySerializer;

    public CustomSerializerProvider(IServiceProvider serviceProvider) : base(serviceProvider)
    {
        _customEntitySerializer = new CustomEntitySerializer(this);
    }

    public override ODataEdmTypeSerializer GetEdmTypeSerializer(IEdmTypeReference edmType)
    {
        // Use our custom serializer for entity types
        return edmType.IsEntity() ? _customEntitySerializer : base.GetEdmTypeSerializer(edmType);
    }
}

Finally, wire it up in your startup configuration:

services.AddControllers()
    .AddOData(options =>
    {
        options.AddRouteComponents("odata", BuildEdmModel(), services =>
        {
            services.AddSingleton<ODataSerializerProvider, CustomSerializerProvider>();
        });
        options.EnableQueryFeatures();
    });

Pros: No changes to query logic, guarantees extra properties are included even if the client didn’t request them.
Cons: Extra properties won’t show up in OData metadata, which might confuse clients relying on it. Also, these properties will bypass $select filtering—they’ll always be in the response.

3. Project to a DTO with AutoMapper (or Similar) #

If you’re already using DTOs, this is the cleanest approach. Define a DTO that includes all your required properties (including the extra ones), then use AutoMapper to project your entity query to the DTO. OData will automatically handle the rest, and you don’t need to mess with OData-specific extensions.

Example setup:

// Your entity
public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string ExtraProperty1 { get; set; }
    public string ExtraProperty2 { get; set; }
}

// Your DTO (matches entity properties plus any extras you want)
public class ProductDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string ExtraProperty1 { get; set; }
    public string ExtraProperty2 { get; set; }
}

// Configure AutoMapper
public class MappingProfile : Profile
{
    public MappingProfile()
    {
        CreateMap<Product, ProductDto>();
    }
}

// In your controller
[EnableQuery]
public IQueryable<ProductDto> Get()
{
    return _dbContext.Products.ProjectTo<ProductDto>(_mapper.ConfigurationProvider);
}

Pros: Super clean, separation of concerns, and works seamlessly with OData’s query capabilities. You control exactly what properties are exposed via the DTO.
Cons: Requires maintaining DTOs and mapping profiles, which adds a bit of overhead if you have many entities.

Which One Should You Choose? #

• Pick Option 1 if you want extra properties to respect OData’s query parameters (like $select) and be part of the standard query flow.
• Pick Option 2 if you need to force extra properties into every response, regardless of client requests.
• Pick Option 3 if you already use DTOs and want the simplest, most maintainable solution.

内容的提问来源于stack exchange，提问作者Youcef MERZOUG