Validating derived types while using configuration

Topics: Validation Application Block
Mar 10, 2010 at 8:56 AM

I'm using Enterprise Library Validation Application Block 4.1.

When we want to validate a derived object, we can get a proper validator it using the ValidationFactory.CreateValidator(Type) method to get a proper validator. This works pretty well when the validation is defined using attributes, but when the validation is defined in the configuration file, it doesn't seem to work. The validator returned from the CreateValidator(Type) method only wraps the validators that are defined for that exact type in the configuration. Validators from the base types don't seem to get used.

Is my observation correct and if so is there a way to resolve this? Is there a way to flag the type in the configuration to have base types? How does version 5.0 handle this?


Mar 11, 2010 at 5:09 AM


Your observation is correct. Please see this FAQ item, there is a workaround suggested, please see if it is feasible for you .

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.

Mar 11, 2010 at 7:45 AM
Edited Mar 11, 2010 at 7:46 AM


What you are basically saying that this is not supported. I hope you can imagine that copying all validation from base class to sub class to sub class is time consuming and error prone. Enterprise Library 5.0 will not allow this configuration inheritence?

A solution that comes to mind is manually iterating the type hierarchy, as follows:


public IEnumerable<ValidationResult> Validate(
    IEnumerable<object> entities)
        from entity in entities
        from type in GetTypeHierarchyOf(entity.GetType())
        let validator = ValidationFactory.CreateValidator(type)
        let results = validator.Validate(entity)
        where !results.IsValid
        from result in results
        select result;
// Return the type and all its base types
private static IEnumerable<Type> GetTypeHierarchyOf(Type type)
    while (type != null)
        yield return type;
        type = type.BaseType;

While this might work with a configuration source, this will fail when objects are decorated with attributes, because in that situation we’ll get duplicate validation errors. And while I’m not sure, this will probably also break when using the ObjectCollectionValidator of VAB 5.0. When it is configured to validate a collection of inherited types, it will probably only take the validators for the most derived type.


A second option that I can think of is building up a new inheritance-ready configuration file, based on an existing one. Just like this solution where multiple configuration files are merged to one single configuration, the process of duplicating validators could be automated. However, this is a lot of work and should presumably also be done for possible interfaces.

I like to hear your opinion on this matter.

Mar 12, 2010 at 1:52 AM

On the first approach, yes, validation errors will get duplicated once types were decorate with attributes.  Am I right that the Validate method will be called after performing an initial call to the the Validation.Validate method passing the each object as is (meaning without creating a validator first based on its base type)?  If this is the case, then I think the scenario involving the ObjectCollectionValidator will have no other problem aside from the fact that errors will also be duplicated when attributes are used since the new behavior of that validator is to validate based on the actual type.  (The initial call to Validation.Validate for each object on  the list will return the correct validation messages for each type).

On the second option, as I understand, you'll specifically use the method of passing an IConfigurationSource when performing validation and that would ignore attributes on type even when used, am I right?  This is more preferrable I think than the first one but as you said, requires more work.  If I could think of another workaround for this, I'll let  you know.


Sarah Urmeneta
Global Technology and Solutions
Avanade, Inc.

Mar 12, 2010 at 10:07 AM

I use this first approach to validate a set of entities before submitting them to the database. The Validation.Validate method is completely skipped, because it is only able to handle a single specific type. For this reason I use the ValidationFactory.CreateValidator for each object in a collection of specified objects. This is especially useful when using O/RM frameworks, such as LINQ to SQL and Entity Framework (you can read here how I exactly do this).

I looked at the source for the 4.1 ObjectCollectionValidator and this first approach will fail in certain situations when the ObjectCollectionValidator is used. Take for instance the scenario where we define a type Customer and a derived type PreferredCustomer and a type PreferredCustomerGroup, containing a collection of PreferredCustomers. All validations are configured using a configuration file and Customer validations are not duplicated for PreferredCustomer. The configuration also holds the ObjectCollectionValidator for the PreferredCustomers property on PreferredCustomerGroup. The property uses the following configuration: <validator type="ObjectCollectionValidator" targetType="PreferredCustomer" />.

With this setup, validating a PreferredCustomer directly with my Validate(IEnumerable<object> entities) will be successful, because the method will iterate the PreferredCustomer's base types to get the all validations. However, when we validate the PreferredCustomerGroup entity, the validation could yield invalid results, because the ObjectCollectionValidator will simply get a single validator using the ValidationFactory.CreateValidator(this.targetType, this.targetRuleSet) method. The ObjectCollectionValidator (of course) doesn't walk the type hierarchy and the Customer validations are not triggered. The PreferredCustomers on PreferredCustomerGroup may seem valid, while in fact they could be invalid.

While I'm not sure about the ObjectCollectionValidator in VAB 5.0, I expect it to behave the same.

With the second approach, I build a custom IConfigurationSource and supply it to the overload of ValidationFactory.CreateValidator that takes an IConfigurationSource as you correctly guessed.
I start to believe that this approach will both for version 4.1 and 5.0 be the only approach that will yield correct results (besides of course, manually duplicating validations for derived types in the config file).

If you find an easier workaround, please let me know. I will do the same.

Mar 23, 2010 at 9:22 PM

I created an implementation of the second approach (where an configuration source is transformed in a new configuration source) that allows inheritance support of configured validators. I must admit that it took me an awful lot of code to get this working, so I would really appreciate if the EntLib developers would consider this feature for a next big release.

In the meantime, Validator inheritance while using Validation Application Block configuration files would do the trick.