This serves two purposes:
- On a multi-tier architecture, I could make sure presentation tiers had no access to validation structures but still use the validation classes, because the validation configuration would be deployed only at the back-end, where my BLL resides.
- I could lookup all messages being issued by my application on a single file. Of course this would be possible by using Resources, but that is a lot of work when not planning to localize the application.
So I delved into VAB during the last couple of days. Only to get myself disappointed.
Don't get me wrong, it's still a nice framework, but the two reasons above are linked to storing the validation rules in external configuration files. And that fails miserably because VAB won't validate ancestors rules when using configuration files based validation.
The workaround for that is to replicate every rule for an ancestor at the derived class. Which is not a real solution, since such replication will lead to errors quicker than you can say "what".
I think this defeats the purpose of using configuration files. VAB is a choice only when dealing with complex system, and on such systems, there probably will have at least some cases of inheritance.