Skip to content
This repository was archived by the owner on Dec 14, 2018. It is now read-only.

Discuss adding server side validation to value type model properties by default. #2776

Closed
NTaylorMullen opened this issue Jul 2, 2015 · 3 comments

Comments

@NTaylorMullen
Copy link
Contributor

Today in MVC6 having the following model:

public class Person
{
    public int Id { get; set; }
}

Will result in client side validation with 0 server side validation (unless specifying BindingBehaviorAttribute with BindingBehavior.Required).

This differs from what happened in MVC5; model state would be invalid due to server side validation opting in ValueType properties. However, in WebAPI not providing a value for a ValueType property when model binding was 100% ok and did not result in any ModelState errors.

Given the different behavior in the old MVC/WebAPI systems we should discuss the right approach for this in MVC6.

Related conversation that spurred this: #2720 (comment)

/cc @rynowak @Eilon @dougbu

@rynowak
Copy link
Member

rynowak commented Jul 22, 2015

Decision here is to bring back the implicit [BindRequired] for value-types. If you need to make something optional, it can be customized:

  • using [BindingBehavior(BindingBehavior.Optional)]
  • a custom MMP
  • using a nullable type (int?)

@rynowak
Copy link
Member

rynowak commented Aug 14, 2015

We've done more investigation here, and the data above isn't correct about MVC 5's behavior.

In MVC 5 the absence of a field does not result in a validation error for a value type property. You only get the validation error if you submit an empty value.

This is critical for compatibility because Create views that scaffolding generates will omit the Id for the model. With the fix in a6ce9ab - you'll see an error in this very common scenario.

rynowak added a commit that referenced this issue Aug 14, 2015
some more tests.

This change reverts the behavior change from
a6ce9ab and adds more tests around the
scneario that was actually broken.

The right behavior is that unconvertable values result in a validation
error. There's no special behavior around value types and required values.
rynowak added a commit that referenced this issue Aug 16, 2015
some more tests.

This change reverts the behavior change from
a6ce9ab and adds more tests around the
scneario that was actually broken.

The right behavior is that unconvertable values result in a validation
error. There's no special behavior around value types and required values.
@rynowak
Copy link
Member

rynowak commented Aug 16, 2015

07fabde

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants