Validating all items in a collection rather than stopping at the first failure.

[tknarr-starbucks]

I noticed the code stops at the first item in a collection that fails validation. Most of the time I prefer to get all failures for the collection at once so I don't have to do multiple iterations to fix all the validation failures in a collection. It looked like a simple fix to change this behavior, so I did the work and added test cases and it seems like it works without breaking anything. I'm going to open a PR with the change for review.

Would this be behavior that'd be better controlled by a flag, or just made the norm?

[DamianEdwards]

Thanks for the suggestion. Do you know if the validation logic in ASP.NET Core MVC continues validating collection items after one fails? I'd like the defaults of this library to match the defaults there as much as possible.

[tknarr-starbucks]

The standard data validation stuff has a flag controlling whether it stops at the first failure or continues checking all properties. It validates the collection property itself but I couldn't find a way to make it validate the contents of a collection. Hence why I went looking for alternatives to writing recursive validation myself. MiniValidation adds recursion, but lacks the validateAllProperties flag that the core library has (It looks like it always validates all properties?). I was thinking that adding that flag in with behavior:

• If false, stop at the first property or first item in a collection that fails validation. That'd produce a maximum of 1 validation error message.
• If true, validate all properties and all members of collections. That'd produce a maximum of 1 validation error message per property or collection item that failed validation.

If the recurse flag wasn't set, then it'd continue not validating the contents of collections. There's a bunch of variations if you get into things like "recurse through the entire object tree validating all object properties, but for collections stop on the first item that fails", but IMO that's getting a bit too complicated. I think the two common use cases are "only care about the result, so stop as soon as we know it's going to fail" and "care about why it failed, so identify as many of the failures as we reasonably can", right?

[DamianEdwards]

The core System.ComponentModel.DataAnnotations.Validator APIs don't support recursion or collection validation at all. The validateAllProperties argument on the TryValidateObject method is used to control whether properties with validation attributes other than RequiredAttribute are validated. There is special logic in the core validation libraries that ensures that RequireValidation for all properties passes before ever considering validating other ValidationAttributes and to my knowledge that can't be changed. The core validation logic also considers whether the call site supports a list of validation results or just a true/false response, and controls early exit on error based on that (no point validating anything beyond the first failure if the end result is just true or false).

All that said, my goal with this library was to closely match what ASP.NET Core MVCs model validation logic is, which itself is layered on top of System.ComponentModel.DataAnnotations.Validator like MiniValidation is. My understanding was it exits early when doing collection validation as it's just more work for the server to do to continue validating the model from the request. I don't think it lets you control this behavior but I admit I haven't done an exhaustive comparison.

If we wanted to introduce an "only care about the result" scenario (i.e. true/false) then I think I'd prefer adding top-level IsValid methods that are optimized for returning as soon as possible, i.e. break as soon as a validation failure is encountered. Like you I'm a bit concerned with adding support for various behavior options as supporting all the combinations would get pretty unwieldly quickly.

[tknarr-starbucks]

I'll dig into the docs and code for the Validator class and the ASP.Net model validation to see what's controllable and what the default behavior is. I was starting from the basic Validator behavior, not factoring in the MVC model validation. I'm going on the principle that if it's called without making any changes in the calling code then it's behavior shouldn't change.