Design extensibility for executors #6822
Conversation
|
/cc @pranavkm |
|
I did one as an example. If we like the pattern I will go ahead and port the rest. |
| { | ||
| public interface IActionResultExecutor<TResult> where TResult : IActionResult | ||
| { | ||
| Task ExecuteAsync(ActionContext context, TResult result); |
There was a problem hiding this comment.
Most of the executors we have already follow this pattern, I'm just adding an interface.
I have big plans for these..... (trails off in a sinister way)
|
I like it! 😍 I'm already using The formatting pipeline infrastructure is still a bit too tightly coupled to MVC, IMO. Have you guys thought about decoupling it so it could be used in other MW as well? (I'm guessing aspnet/Diagnostics#346 (comment) is related to this?) |
Yes, but it's not planned for right now
conneg is one of a few things in MVC that has an opinion at all. There's no technical need for it to be coupled, but we'd have to re-examine those decisions. |
|
|
||
| namespace Microsoft.AspNetCore.Mvc.Infrastructure | ||
| { | ||
| public interface IActionResultExecutor<TResult> where TResult : IActionResult |
There was a problem hiding this comment.
Is there any value in making this contravariant? Maybe for scenarios like IActionResultExecutor<NotFoundResult> = new StatusCodeResultExecutor();
There was a problem hiding this comment.
Hmm, I don't think it can hurt.
rynowak
force-pushed
the
rynowak/executor
branch
3 times, most recently
from
602dd8a to
2dcc293
Compare
|
@pranavkm ping |
rynowak
force-pushed
the
rynowak/executor
branch
4 times, most recently
from
410e738 to
82c44cb
Compare
| public override void ExecuteResult(ActionContext context) | ||
| { | ||
| if (context == null) | ||
| { | ||
| throw new ArgumentNullException(nameof(context)); | ||
| } | ||
|
|
||
| var executor = context.HttpContext.RequestServices.GetRequiredService<RedirectResultExecutor>(); | ||
| executor.Execute(context, this); | ||
| var services = context.HttpContext.RequestServices; |
There was a problem hiding this comment.
Could we have these call the executor and block on it? In the default case, it should be fine since the executor is entirely synchronous.
There was a problem hiding this comment.
I don't want to put a .Result in the code. You could implement these interfaces and do some arbitrary stuff
| @@ -145,5 +145,25 @@ | |||
| "TypeId": "public class Microsoft.AspNetCore.Mvc.ModelBinding.Metadata.DefaultModelMetadata : Microsoft.AspNetCore.Mvc.ModelBinding.ModelMetadata", | |||
| "MemberId": "public override Microsoft.AspNetCore.Mvc.ModelBinding.Metadata.IModelBindingMessageProvider get_ModelBindingMessageProvider()", | |||
| "Kind": "Removal" | |||
| }, | |||
| { | |||
| { | ||
| await executor.ExecuteAsync(context, view, this); | ||
| } | ||
| var executor = context.HttpContext.RequestServices.GetRequiredService<IActionResultExecutor<ViewResult>>(); |
| @@ -176,6 +178,29 @@ public virtual Task ExecuteAsync(ActionContext actionContext, IView view, ViewRe | |||
| viewResult.StatusCode); | |||
| } | |||
|
|
|||
| /// <inheritdoc /> | |||
| public async Task ExecuteAsync(ActionContext context, ViewResult result) | |||
There was a problem hiding this comment.
Could we remove the now unused overload since the type was in .Internal?
| using Microsoft.Extensions.Logging; | ||
|
|
||
| namespace Microsoft.AspNetCore.Mvc.Internal | ||
| namespace Microsoft.AspNetCore.Mvc.Infrastructure |
There was a problem hiding this comment.
Is the namespace change to facilitate subclassing?
We have all of these executors but they aren't really documented/supported for extensibility today. This change introduces a pattern for action result executors so we can make them extensible.
rynowak
force-pushed
the
rynowak/executor
branch
from
d50ab0d to
d640115
Compare
We have all of these executors but they aren't really
documented/supported for extensibility today. This change introduces a
pattern for action result executors so we can make them extensible.