-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Can InputFormatterContext be replaced by ModelBindingContext #2330
Comments
A possible scenario is where users might want to deserialize the request stream before model binding stage, example authorization or resource filters, in which case Also wondering other scenario where there are no parameters on the action, but the user might want to deserialize within it, in this case i guess we would not have the |
@pranavkm we're going to do something about the layering here as part of the current milestone. There's a few bugs already tracking it.
@kichalla we should more or less consider our guidance about what to do in various filter stages to be prescriptive. If it becomes hard to do something that we never intended you to do, then that's alright. That said, I don't see InputFormatter having its own context as a problem to be solved. The layering problems related to the current state of all of this should be addressed. |
I guess the discussion was more along the lines of do we need the |
@rynowak Please make it layer like a delicious cake. |
@pranavkm I do not think that we should be using @rynowak can you point to the relevant layering bugs for better understanding. |
Shouldn't that happen as part of the |
as part of |
Wouldn't that argument also apply to model binders \ value providers \ validators? |
Model binders already have an operation binding context, which gives them access to all they can need. Not getting into a debate here, I am not arguing if it is necessary or not, I am just mentioning why it was done 😄 . |
The other issue here is that InputFormatters need ModelState - and not just ActionContext.ModelState - that breaks scenarios where you manually call model binding. Formatters are intentionally a bit more constrained than a model binder, and they really don't need everything. They don't need the action, if you want to make per-action decisions then use resource filters. Proposal:
|
This change simplifies InputFormatterContext/OutputFormatterContext by swapping ActionContext for HttpContext. This change is important especially for InputFormatterContext as it decouples ModelState and ActionContext - allowing us to fix a related bug where the _wrong_ ModelState can be passed in for a TryUpdateModel operation.
Today
IInputFormatter
get access to theActionContext
and theModelType
without getting access to all the properties thatModelBindingContext
exposes. Could we replace it withModelBindingContext
so it's the same programming model when writing binders or formatters? Additionally, if we remove the dependency onActionContext
, we could change it so that formatters only rely on the ModelBinding assembly as opposed to Mvc.Core. Might make the layering a bit cleaner.The text was updated successfully, but these errors were encountered: