IValidator Guidelines

Do

• Use built-in property-level validators for general purpose-validation
• Use many small validators for the same object and rules set when the validator size gets large. They're composed at runtime anyway, and smaller valiators are easier to write and test.
• Provide descriptive messages for your validation results. Developers or end-users will be reading those messages to figure out what went wrong.
• Provide as much information as possible on each validation result.
• Use separate rules sets for UI and service-layer validations (separate objects would be even better!)
• Establish a set of conventions for rules set names so that they are discoverable. Even better, use a defined list of constants or an enum to track them.

Don't

• Embed service or database calls in a validator that is used at the UI layer. Some UI consumers will run validation as the user makes changes and the UI needs to remain performant.