Options Validation: Support DataAnnotations

[HaoK]

From Experience review with @ajcvickers @DamianEdwards @Eilon @davidfowl :

We should support DataAnnotations on the POCO for 2.2:

for example:

public class MyOptions 
{
        [Required]
        public string Key { get; set; }
   
        [Range(18,99, ErrorMessage="Age should be between 18 and 99")] 
        public int Age { get; set; } 
 
        [DataType(DataType.PhoneNumber)] 
        [Phone] 
        Public string PhoneNumber { get; set; } 
 
        [DataType(DataType.EmailAddress)] 
        [EmailAddress] 
        Public string Email { get; set; } 
}

Need to figure out how to opt in, via new default overload?
services.AddOptions<MyOptions>.[Auto]Validate()

[thiagolunardi]

The ability to add a binding name will be handy. Like JsonProperty.

public class MyOptions
{
    [JsonProperty("ASPNETCORE_ENVIRONMENT")]
    public string Environment { get; set; }
}

Sometimes the host environment set some values, and I'd like to read it using my app language.

[gautelo]

@thiagolunardi I agree. This was suggested in issue #775. It was decided to implement this sort of thing through the BinderOptions instead as part of #789.

Personally I feel like implementing yet another way to serialize properties instead of using what's already there is a mistake. I would much rather use attributes for this.

I believe the counter argument is that sometimes you don't own the options type and can't add attributes to it. In my mind that would be a good argument for implementing 789 as a fallback. But attributes should be the primary solution.

Especially now that we're adding validation through standardized attributes, I feel like that sets a precedent for also using attributes for serialization/property mapping. After all, the same argument could apply to validation - that rules could be added to BinderOptions or some other structure disconnected from the model in case one does not own the options model.

So, I feel like the decision to scrap 775 Should be reconsidered. Attributes should be the common approach for serialization and validation alike, with BinderOptions as a fallback only.

[bdovaz]

I agree with @gautelo., Json.NET supports DataMember attribute although it has already JsonProperty attribute itself.

[HaoK]

Options and Configuration are decoupled, we can certainly consider revisiting and unifying the binder with whatever we end up for Options Validation as the binder primarily exists to bind config to options.

[HaoK]

It likely would end up similar to how options validation works, it would be a sugar method that generated the appropriate underlying binderoptions, as opposed to a replacement for the binder options.

[gautelo]

@HaoK Sure, either way works. As a library consumer I'm not really fussed if DataMembers are sugar on top of BinderOptions or the other way around, as long as I can do either one.