Enterprise Library Validation Block - Should validation be placed on class or interface?

Question

I am not sure where the best place to put validation (using the Enterprise Library Validation Block) is? Should it be on the class or on the interface?

Things that may effect it

• Validation rules would not be changed in classes which inherit from the interface.
• Validation rules would not be changed in classes which inherit from the class.
• Inheritance will occur from the class in most cases - I suspect some fringe cases to inherit from the interface (but I would try and avoid it).
• The interface main use is for DI which will be done with the Unity block.

Answer 1

The way you are trying to use the Validation Block with DI, I dont think its a problem if you set the attributes at interface level. Also, I dont think it should create problems in the inheritance chain. However, I have mostly seen this block used at class level, with an intent to keep interfaces not over specify things. IMO i dont see a big threat in doing this.

Answer 2

For the sake of completeness I decided to write a small test to make sure it would work as expected and it does, I'm just posting it here in case anyone else wants it in future.

using System;
using Microsoft.Practices.EnterpriseLibrary.Validation;
using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

namespace ConsoleApplication1
{
    class Program
    {
    static void Main(string[] args)
    {
        ISpike spike = new Spike();
        spike.Name = "A really long name that will fail.";
        ValidationResults r = Validation.Validate<ISpike>(spike);
        if (!r.IsValid)
        {
            throw new InvalidOperationException("Validation error found.");
        }

    }
}

public class Spike : ConsoleApplication1.ISpike
{
    public string Name { get; set; }
}

interface ISpike
{
    [StringLengthValidator(2, 5)]
    string Name { get; set; }
}
}

Answer 3

Be very careful here, your test is too simple.

This will not work as you expect for SelfValidation Validators or Class Validators, only for the simple property validators like you have there.

Also, if you are using the PropertyProxyValidator in an ASP.NET page, iI don;t believe it will work either, because it only looks a field validators, not inherited/implemented validators...

Yes big holes in the VAB if you ask me..