Support Keyed Services in MVC

[adityamandaleeka]

Background and Motivation

To support Keyed Services in MVC, we need to make a small change to BindingInfo.

Proposed API

namespace Microsoft.AspNetCore.Http;

public class BindingInfo
{
+    public object? ServiceKey { get; set; }
}

Usage Examples

This property will be set by calling BindingInfo.GetBindingInfo(IEnumerable<object> attributes), like other existing property (PropertyFilterProvider, RequestPredicate, etc.)

Attributes are already extracted for this method.

Alternative Designs

Without this property, we will need to do some reflection for all binding that comes from the service provider.

var attribute = context.Metadata.Identity.ParameterInfo?.GetCustomAttribute<FromKeyedServicesAttribute>();
if (attribute?.Key == null)
{
    // existing path
}
else
{
   // keyed service path
}

This will be expensive, since it will be done for all parameter that binds from the service provider.

Risks

A custom implementation of IModelBinder that target BindingSource.Services could resolve a non-keyed service when a keyed one was requested if they don't check BindingInfo.ServiceKey. But that's also the reason why I think this property needs to be public and not internal.

I don't expect a performance hit since the attributes are already populated when calling BindingInfo.GetBindingInfo.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes:

• Is there any place more logical than BindingInfo for this?
  • Not that we know of. This allows us to cache the key for the parameter relatively early.
• Should this be internal?
  • While we don't have an exact use case for external users, things like ApiVersioning use BindingInfo, and it would feel like a gap to omit this information when most of the properties are public.

API Approved!

namespace Microsoft.AspNetCore.Http;

public class BindingInfo
{
+    public object? ServiceKey { get; set; }
}

[BrennanConroy]

Done via #50145