Update RouteHandlerFilterContext.Parameters API

[captainsafia]

Follow-up to #40491

- public sealed class RouteHandlerInvocationContext
+ public class RouteHandlerInvocationContext
{
-  public HttpContext HttpContext { get; }
+ public virtual HttpContext HttpContext { get; }

- public List<object?> Parameters { get; }
+ public virtual List<object?> Parameters { get; }

+ public virtual T GetParameter<T>(int index) { }
}

[captainsafia]

Moving this back into .NET 7 Planning to prioritize completing the performance tests in #40655 for preview3.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[captainsafia]

We've added performance tests for some basic scenarios with minimal APIs and route handler filters.

• A route handler with no parameters and no filter
• A route handler with no parameters and a "pass through filter"
• A route handler with parameters and a "pass through filter"
• A route handler with parameters and a filter

All the route handlers above tested on a string input/output for the route handler. While testing other input/output types might provide more "real world" values, the bare scenario is sufficient for observing the net impact of the barebones filters logic.

All told, adding a filter to an endpoint reduces throughput (measured in RPS) by about 9%. There's generally a bigger impact when adding parameters to an endpoint filter and parameter processing is a larger cost in the process than endpoint filters.

Regardless of the perf impact, IMO, this work is relevant to pursue because exposing parameters as an untyped list is 🤢 .

[ghost]

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:

• Should we make the generic implementations public?
  • This seems noisy and low value.
• Abstract?
  • Yes. Let's save some fields
• Parameter -> ParameterValues? Arguments?
  • Let's go with Arguments and GetArguments since "Parameter variables are used to import arguments into functions" https://developer.mozilla.org/en-US/docs/Glossary/Parameter

- public sealed class RouteHandlerInvocationContext
+ public abstract class RouteHandlerInvocationContext
{
-     public RouteHandlerInvocationContext(HttpContext httpContext, params object[] parameters)

-    public HttpContext HttpContext { get; }
+    public abstract HttpContext HttpContext { get; }

-     public IList<object?> Parameters { get; }
+     public abstract IList<object?> Arguments { get; }

+     public abstract T GetArgument<T>(int index) { }
}

+ public class DefaultRouteHandlerInvocationContext : RouteHandlerInvocationContext
+ {
+     public RouteHandlerInvocationContext(HttpContext httpContext, params object[] parameters)
+
+     public override HttpContext HttpContext { get; }
+     public override IList<object?> Arguments { get; }
+     public override T GetArgument<T>(int index) { }
+ }