Question

My view model has a [Required] non-nullable int property, selected by a DropDownListFor. If the list to choose from is empty, ModelState.IsValid is true.

My model has a Required int property:

public class MyModel
{
    [Required]
    public int PickedValue  { get; set;}

    IEnumerable<SelectListItem> Items { get; set; }
}

In my Create view, I render a <select> element:

@Html.DropDownListFor(model => model.PickedValue, model.Items)

And in my controller, if the model.Items list is empty (no elements to choose from), ModelState.IsValid is true:

[HttpPost]
public ActionResult Create( MyModel model )
{
    if( ModelState.IsValid )
    {
        // true, and ModelState.Keys doesn't contain PickedValue because it was never POSTed.
    }
    //...
 }

Now, the problem goes away if:

1. PickedValue is Nullable (int?), or
2. if I have an empty item in my <select> – @Html.DropDownListFor(model => model.PickedValue, model.Items, ""), or
3. if client-side validation is enabled (since the action is never fired).

Is there a way to force ModelState.IsValid to be false if some of MyModel‘s properties are [Required] but are missing from the POST data? Shouldn’t this be the default behavior?

Answer 1

In your case, I think it would probably be better to make PickedValue a nullable int. If there is a chance that your DropDownList has no items, then null should be a possible value for your PickedValue.

Reply to comments

That makes sense but doesn’t answer my original question… Is there a
way to force ModelState.IsValid to be false if some of MyModel’s
properties are [Required] but are missing from the POST data?
Shouldn’t this be the default behavior?

When it comes to ints, doubles, bools, and other primitives that cannot have a null value, when the DefaultModelBinder receives no data for them in the HTTP request, it must still construct a model instance. Therefore, the model gets constructed and the properties are initialized to their default values. In the case if int, this means it will be initialized to zero. Since nothing is received in the HTTP request, this means the int never gets set, hence it will always be zero. Have you tried giving your int a [Range] validator instead of a [Required] validator? This should validate that it is not zero:

[Range(1, int.MaxValue)]
public int PickedValue  { get; set; }

I’d like to avoid changing the model because it’s already a common
pattern in my code… Plus making a property in the model nullable to
force it not to be null seems counter-intuitive.

Just because it’s a common pattern in your code doesn’t mean it’s correct. I have to reiterate my original answer: If it is possible for your dropdown list to not have any items, then your model should allow null for its selected value.

This is one reason why it’s good practice to have separate entity & viewmodel layers. In your domain entities, a relationship might be required. However when a user is first presented with a form to select that relationship, you either have to give them a default or empty selected dropdown item. In this case, the foreign key in the entity might be an int, but the representation in the viewmodel should be a Nullable<int>. For this reason alone I don’t think it’s counter-intuitive to make something nullable just to make sure it is not null. You make it nullable in the viewmodel so you can give the user a form with a blank value, and require them to fill it in.