| Microsoft Enterprise Library 5.0 |
| How Validators Are Created |
|
|
When the application block creates a validator, it uses a set of requirements to determine which types and members of those types can be associated with that validator. (Members can be methods, properties, and fields.)
In general, when the application block creates a validator, it evaluates the associated type and its members. Only members that have the following characteristics can be associated with a validator:
- They must be public members.
- Methods must be non-void and take no parameters.
- Properties must be readable.
Self validation has a different set of requirements. They are the following:
- Self validation applies only to methods.
- A self validation method can be non-public.
- The method signature must be void [method](ValidationResults).
- Self validation can apply to inherited methods but not to methods that are private and inherited.
Creating Validators with Configuration
Configuration has the following characteristic:
- Identifier collisions should not occur because names must be unique and the signatures for the methods are known beforehand.
Creating Validators with Attributes
In general, attributes can have classes and members as targets. The requirements are the following:
- Validators that apply to specific .NET Framework types, such as the regular expression validator and the string length validator, cannot be applied to classes.
- The SelfValidation attribute only applies to methods.
- The only cases where attributes can be applied to parameters are with WCF integration and when using the policy injection and interception features of Unity. For more information, see Using Interception and Policy Injection.
To report documentation errors or provide feedback on this documentation, please send email to [email protected].
Copyright © 2010 by Microsoft Corporation. All rights reserved.