Export (0) Print
Expand All

Validation and Inheritance

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.

If you use inheritance then you need to know how the validation rules are applied throughout the class hierarchy. Here is an example of a simple hierarchy, where class PreferredCustomer inherits from class Customer. (The validator attributes used in the example, such as CustomerNameValidator refer to custom validators and are not validators included with the Validation Application Block.)

Public Class Customer
{
     [CustomerNameValidator]
     public string Name
    {
        get
        {
            /* ... */
        } 
        set
        {
            /* ... */
        }
    }

     [DiscountValidator]
     public virtual double Discount
    {
        get
        {
            /* ... */
        } 
        set
        {
           /* ... */
        }
    }
}

public class PreferredCustomer : Customer
{
    [PreferredDiscountValidator]
    public override double Discount
    {
        get
        {
            /* ... */
        }
        set
        {
            /* ... */

        }
    }
}

In this example the PreferredCustomer class derives from the Customer class, and it also overrides the Discount property.

There are two rules for how validators work within a class hierarchy. They are:

  • If a derived class inherits a member and does not override it then the member's validators from the base class apply to the derived class.
  • If a derived class inherits a member but overrides it then the member's attributes from the base class do not apply to the derived class.

In this example, the CustomerNameValidator attribute applies to the PreferredCustomer class but the DiscountValidator attribute does not. Instead, the PreferredDiscountValidator attribute applies.

If this is not the desired behavior, you can use validators of base classes to check instances of derived classes. The following code example shows how to do this.

Validator<Customer> customerValidator = 
ValidationFactory.CreateValidator<Customer>();

PreferredCustomer myPreferredCustomer = new PreferredCustomer( /* arguments */);
ValidationResults r = customerValidator.Validate(myPreferredCustomer);

This example validates a PreferredCustomer object. However, the validation is based on the attributes of the Customer base class. The validation rules defined on the PreferredCustomer class are not applied.

You can use the CreateValidator(Type) overload of the ValidationFactory class to create a validator that is specific to a class that you provide at runtime.

public ValidationResults CheckObject(object obj)
{
   if (obj != null)
   {
      Validator v = ValidationFactory.CreateValidator(obj.GetType());
      return v.Validate(obj);
  }
}

This example creates a validator based on the run-time type of the input argument to the CheckObject method.

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The latest Enterprise Library information can be found at the Enterprise Library site.
Show:
© 2014 Microsoft