Add API to turn delegate or MethodInfo into a RequestDelegate

[davidfowl]

Background and Motivation

MVC Controllers have this magic power baked inside of them to allow dispatching HTTP requests to an arbitrarily shaped method on a controller (called actions). As part of the work to make this more accessible, we want to expose a zero dependency building block from lower in the stack that enables the same thing with arbitrary methods and delegates. This lets library authors build convenient and complex request handling logic without having to take big dependencies on controllers or mvc.

Proposed API

namespace Microsoft.AspNetCore.Http
{
+    public sealed class RequestDelegateFactory
+    {
+        public static RequestDelegate Create(Delegate requestHandler);
+        public static RequestDelegate Create(MethodInfo methodInfo, Func<HttpContext, object> targetFactory);
+        public static RequestDelegate Create(MethodInfo methodInfo);
+    }
}

Usage Examples

There are 2 scenarios

1. Wrapping a fixed Delegate
2. MethodInfo with or without "this"

Enhanced routing (MapAction) with is number 1, MVC controllers are examples of number 2.

1. Dispatch with delegate

Func<string> hello = () => "Hello World";
RequestDelegate rd1 = RequestDelegateFa.Build(hello);
app.Run(rd1);

RequestDelegate rd2 = RequestDelegateFactory.Create(Func<string>)MyClass.Hello);
app.Run(rd2);

public class MyClass
{
    public static string Hello() => "Hello World";
}

2a. Class dispatch with instance

MethodInfo methodInfo = typeof(MyClass).GetMethod(nameof(MyClass.Hello));

// This will create an instance of MyClass per request, giving the factory a chance to construct
// MyClass using per request scoped objects
RequestDelegate rd1 = RequestDelegateFactory.Create(methodInfo, context => new MyClass());

// Example with DI
RequestDelegate rd2 = RequestDelegateFactory.Create(methodInfo, context => context.RequestServices.GetRequiredService<MyClass>());

app.Run(rd1);
app.Run(rd2);

public class MyClass
{
    public string Hello() => "Hello World";
}

2a. Class dispatch with static

MethodInfo methodInfo = typeof(MyClass).GetMethod(nameof(MyClass.Hello));

RequestDelegate rd = RequestDelegateFactory.Create(methodInfo);

app.Run(rd);

public class MyClass
{
    public static string Hello() => "Hello World";
}

Alternatives

Don't expose this building block and expose it on more places. Middleware, Routing, IApplicationBuilder etc.

PS: We might also need to consider options that control behavior in the future.

cc @pranavkm

[halter73]

Don't expose this building block and expose it on more places. Middleware, Routing, IApplicationBuilder etc.

We should expose this building block. I see no reason to be overly prescriptive and make it difficult for developers to get at this RequestDelegate. We shouldn't assume we can think of all the ways developers might possibly want to use it. If we don't expose this, people will do hacks like build a whole middleware pipeline just to get at a RequestDelegate.

We don't technically need all of these overloads. Build(MethodInfo methodInfo, Func<HttpContext, object> targetFactory) can be implemented by calling Build(Delegate action) or vice-versa. Efficiently using the Build(Delegate action) overload if you have a nontrivial targetFactory would likely require expression tree compilation or something similarly complicated, so I'm completely fine keeping the other overloads for convenience.

If we do decide to reduce the overloads, Build(Delegate action) is the one I most want to keep though. I think it will see the most usage outside of framework code.

[davidfowl]

We don't technically need all of these overloads. Build(MethodInfo methodInfo, Func<HttpContext, object> targetFactory) can be implemented by calling Build(Delegate action) or vice-versa. Efficiently using the Build(Delegate action) overload if you have a nontrivial targetFactory would likely require expression tree compilation or something similarly complicated, so I'm completely fine keeping the other overloads for convenience.

I think it's too difficult. I tried it but happy to be proven wrong here.

[halter73]

I think it's too difficult. I tried it but happy to be proven wrong here.

I haven't tried it yet, but I believe you. Adding the attributes back to the generated Delegate's MethodInfo might be a blocker.

I do like all 3 overloads. I'm adding the MethodInfo overloads to #31171 now.

[mumby0168]

Will there be a way to have the framework pick these up via reflection? A bit like services.AddControllers() detects all controllers in the assembly. Maybe marking the "special" methods with an attribute?

Thanks,
Billy

[davidfowl]

@mumby0168 explicitly no. No scanning will be done by default to discover these, we already have that framework (mvc). This building blocking can be used to build that sort of thing if you want but we won’t be building that again.

[JamesNK]

Is there a way to get access to the HttpContext with an abritary method?