Add support for validation attributes on parameters

[rynowak]

---

Update: As of 2.1.0, validation attributes are allowed on controller parameters, bound controller parameters, page model properties and handler method parameters. To use this feature, the application must opt in to 2.1 (or newer) compatibility behavior.

services.AddMvc()
                .SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

[billpratt]

I am very excited for this. So many times I have wanted the following to work:

[HttpGet("test/{testId}")]
public IActionResult Get([FromRoute] string testId, [Required][FromQuery]string name)

or

[HttpGet("test/{testId}")]
public IActionResult Get([FromRoute] string testId, [FromQuery(Required = true)]string name)

Where ModelState would be invalid if name was null or empty. It would be even better, as proposed, to detect invalid state before the action is called. Also having the ability to easily define custom validation parameter attributes is a must, IMO.

I prefer [FromQuery(Required = true)] over a separate [Required] attribute. I propose that Required defaults to true and the developer explicitly states false when not required. I propose also adding a DefaultValue for fallback.

[SteveSandersonMS]

@rynowak This is slightly off-topic but wanted to get a quick sanity check before taking the thought any further. Once again I had to do research to remember the difference between [Required] and [BindRequired]. The only blog post on the subject has no clear conclusion, so it wasn't until finding Doug's comments that it became clear. So now I remember how they serve different purposes, but it's super-non-obvious from the outside.

To avoid all this, has there ever been consideration for a "strict" binding mode, where all non-nullable properties implicitly have [BindRequired]? This feels more intuitive, in that the developer can only allow properties to be optional by using nullable types. As long as you understand C#, you understand which inputs you're going to get. And then [Required] reliably means what you expect, since it behaves the same on int? as it does on string (as opposed to on int, where has no effect). Thinking ahead further, this would also mean that C#8 non-nullable reference types would fit into the pattern: a string! would automatically be binding-required, as opposed to in the current system where MVC would have to supply string.Empty or something, and claim it was valid, which would be pretty lame.

[rynowak]

To avoid all this, has there ever been consideration for a "strict" binding mode, where all non-nullable properties implicitly have

There are lots of ideas, but few of them about how to rationalize this with MVC's current and past behavior. For instance the concept of 'model binding' is hardly relevant to APIs but it's critical for browsers/forms. You will extremely rarely see a complex type used with model binding in an API.

OTOH browers/forms always send a value (empty string) for every input in the form, so what does this proposed behavior add in that case?