Tuesday, January 09, 2007

Validators supplied in the VAB

by tomholl via Tom Hollander's blog on 1/9/2007 9:04:00 PM

We're making great progress with the Validation Application Block in Enterprise Library 3.0, and one of the last remaining tasks is to make sure we include a compelling set of validators with the block. While it's very easy to build your own validator, we don't want everyone to need to build the same validators for each project just because we forgot to include something important.

Here's the set of validators we're currently planning to include - but it's not too late to set us straight if we've missed something! A few things to note are:

• All of these validators can be used from the API, attributes or configuration, although the syntax will vary across these mechansims.
• Some of the validators will use generic parameters, such as RangeValidator<T>. When used from the API, you will be able to use the validator with any type (subject to the generic parameter's constraints). However since you can't use generics in the same way from configuration or attributes, you'll only be able to use common primitive types from these mechanisms.
• All of our validators will include a Negate property, which will change the validator's behavior so that it will fail if the condition is met, rather than when it is not met. This will let you do things like use the "Contains Characters Validator" to check that a string does not contain characters.

First, here are the planned "basic" validators:

• Not Null Validator: Validates that a value is not null
• Range Vailidator (generic, supporting IComparable types): Validates that a value falls within a specified range. The range may be closed or open ended, and may be inclusive or exclusive.
• Relative DateTime Validator: Validates that a DateTime falls within a specified range, relative to now. The range may be closed or open ended, and may be inclusive or exclusive. For example, you could check if a date is between now and 100 years from now, or from 20 days ago to 4 days from now.
• String Length Validator: Validates that a string is of a certain length. May contain a minimum, a maximum or both.
• RegEx Validator: Validates that a string matches a specified regular expression. We'll also include support for "pre-canned" RegEx patterns for common things such as URLs, e-mail addresses, phone numbers etc.
• Contains Characters Validator: Validates that a string contains any, or all of the characters in a specified string.
• Type Conversion Validator: Validates that a string can be converted to a specific type (using a specific culture). For example, this could check that "6.32" can be converted to a Double, or "2007-02-09" can be converted to a DateTime.
• Enum Conversion Validator: Validates that a string can be converted to a value in a specified enum type. For example, this could check that "Blue" could be converted to a value in the Color enum.
• Domain Validator (generic): Validates that a value is included in a specified set, such as {"John", "Paul", "George", "Ringo"} or {2, 3, 5, 7, 11}. If the set only contains one value, this validator can be used to check for equality.

Next, here are our planned "composition" validators:

• And Composite Validator: Indicates that all of a set of child validators must pass
• Or Composite Validator: Indicates that just one of a set of child validators must pass.

Finally, here are our planned "value access" validators, which can be used to specify validation rules on complex objects:

• Property: Applies a validator to a property of an object
• Field: Applies a validator to a field of an object
• Method: Applies a validator to the result of a method of an object (can only be used for methods with no parameters and a non-void result, such as ToString()).
• Object: Specifies that a nested object needs to be validated by a particular rule set.
• Collection: Specifies that a nested collection of objects needs to be validated by a particular rule set.

Did we miss anything important?