Can InputFormatterContext be replaced by ModelBindingContext

[pranavkm]

Today IInputFormatter get access to the ActionContext and the ModelType without getting access to all the properties that ModelBindingContext exposes. Could we replace it with ModelBindingContext so it's the same programming model when writing binders or formatters? Additionally, if we remove the dependency on ActionContext, 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.

[kichalla]

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 ModelBindingContext would not be available...just curious, what are the properties on the ModelBindingContext that you are referring to?

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 ModelBindingContext?

[rynowak]

@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.

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 ModelBindingContext would not be available..

@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.

[pranavkm]

That said, I don't see InputFormatter having its own context as a problem to be solved.

I guess the discussion was more along the lines of do we need the ActionContext to flown to the formatters - they currently don't make much use of it.,

[danroth27]

@rynowak Please make it layer like a delicious cake.

[harshgMSFT]

@pranavkm I do not think that we should be using ModelBindingContext for input formatters simply because there are too many model binding specific properties on MBC which makes it the MBC ( and not InputFormatterContext). The ActionContext was flown so that any custom input formatter can have access to Request data as well as anything related to the action based on which it can choose to act differently.

@rynowak can you point to the relevant layering bugs for better understanding.

[pranavkm]

as well as anything related to the action based on which it can choose to act differently.

Shouldn't that happen as part of the ResourceFilter?

[harshgMSFT]

as part of ResourceFilter it can add or remove an input formatter or modify a publicly exposed setting of the formatter, but if there is something that input formatter needs to decide ( not applicability but how to deserialize etc). Its really arguable but its more extensible this way.

[pranavkm]

Wouldn't that argument also apply to model binders \ value providers \ validators?

[harshgMSFT]

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 😄 .