Closed malekpour closed 7 years ago
@rynowak ?
@malekpour - what kind of extensibility are you looking for exactly? We can bring back the separation between FilterActionInvoker
and ControllerActionInvoker
once the dust settles with the current perf work - but I have a feeling that these types will always be in the .Internal
namespace.
If you can tell us more about what you're trying to accomplish, we might be able to help.
@rynowak may be extensibility is not a good term, but I'll try to explain how I am currently using FilterActionInvoker
in my RC1 bases project.
We have a microservices implementation which executes dynamic scripts written by developers in an custom web based IDE and stored in database.
For the current production version which is OWIN based, I wrote almost everything from scratch (routing, execution, formatting, binding, authorization, etc...). Now our newer version which is currently in pre production stage we significantly reduced amount of code by using TemplateRoute
, FilterActionInvoker
and AuthorizationPolicyBuilder
.
We didn't need ControllerActionInvoker
so created an ActionInvoker by extending FilterActionInvoker
and our script engines (C#, VB, ADO, PowerShell) will be called by its InvokeActionAsync
, result is an IActionResult
and AspNetCore takes care of the rest like authorization, validation, binding, formatting...
Last week I tried to migrate to RC2, one issue was FilterActionInvoker
does not work with normal ActionDescriptor
and it expects ControllerActionDescriptor
because of this:
code. Other and more important issue is this merging commit https://github.com/aspnet/Mvc/commit/1e02fd2e6b46e78ab3f442752b59eb6f4f70e8e9. Because of that I cannot efficiently use this really useful infrastructure without extending controller related classes.
At this time, in most MVC components are designed to have certain assumptions around what they work with - e.g. the action invoker expects things to be controllers. We can certainly consider increasing the flexibility in the future, but at this time it isn't a goal.
I think we should close this as a won't fix. Extensibility for the invoker is definitely a non-goal. We've rewritten significant aspects of the invoker in every release. I don't think we'll ever want to make it a documented extensibility API.
/cc @Eilon
That's fine. In fact I have implemented my own IActionInvoker
and it is working fine.
In RC1 release,
FilterActionInvoker
was clearly separated fromControllerActionInvoker
and easily reusable/extensible. In RC2 release there are more controller related dependencies involved but class still exists. This commit https://github.com/aspnet/Mvc/commit/1e02fd2e6b46e78ab3f442752b59eb6f4f70e8e9 removes the class completely.Now if I want to use Filters, Binders and Action Results in a controller-less scenario I have to extend
ControllerActionInvoker
or re implement anIActionInvoker
.