Paul Brown

In the first part , we saw how to create custom attributes and rules. Now we'll look at how to implement those attributes. The IValidatable interface defines how consumers can interact with the framework. It indicates that we'll have a collection of BrokenRules and offers a method to perform validation. ValidatableBase implements IValidatable and does most of the work. Your classes simply inherit from ValidatableBase and they are completely functional. You decorate all of the properties you want. /// <summary> /// Interface for class that wish to implement /// validation. /// </summary> public interface IValidatable { /// <summary> /// Gets the collection of business rules that have /// been broken. /// </summary> BrokenRulesCollection BrokenRules { get; } /// <summary> /// Validates the objects. /// </summary> /// <param name="clearBrokenRules">Indicates if the Broken...

I've been working on different ways to implement a validation framework that would really cut down on the code. It  had to be reusable and testable. I also didn't want to swap writing one bunch of repetitive code for another. I'd looked at CSLA from Rockford Lhotka . I liked the way he implemented broken rules but CSLA had a lot of stuff for multiple undo's that was not relevant to my apps. I then used some of ScottGu's stuff for LINQ to SQL and begin using validation methods that threw exceptions. Reusable and custom exceptions made this very testable but I was still writing a bunch of repetitive code. Microsoft's Enterprise Library has a Validation Block that was interesting but really seemed to be overkill.  I did like the declarative nature though and then found this from Imar Spaanjaars . That was more what I was looking for and I could see where I could make some changes. First change was in the naming. NotNullOrEmptyAttribute became RequiredAtt...