Object Validation

I have been working on finding an object validation method that does not suffer from a number of the issues I have seen with some popular validation methods out there. Here is a list of some of the styles that I have looked at and the benefits and weaknesses with each of them.
 
Custom Attribute-Style Validation:
In this style of validation, attributes are applied to object properties that lists the restriction that applies to the property. Using reflection, it’s simple enough to evaluate an object and pull out the validation violations. I built such a framework myself a number of months ago in a non-production prototype at work.
 
There are two additional frameworks I have seen that implement such a style of validation:
 e.g.
public interface IValidate {
    bool IsValid();
}
 
[AttributeUsage(AttributeTargets.Property)]
public class MyRestrictionAttribute: AttributeIValidate {
    string message;
    public MyAttribute(string message) {
        this.message = message;
    }
    public string Message {
        get { return message; }
    }
    public bool IsValid() {
        //TODO: Implement validation logic… 
    }

}

 
 
Pros:
This makes it easy to use inheritance to extend and add your own custom validations. The Validation Application Block also comes with a pretty UI designer to allow you to build these attributes through a nifty wizard.
This method is also the easiest to retro-fit your application with and apply validation in bits and pieces.
 
Cons:
Because attributes are accessible through reflection, all values applied to them must be known at design-time. This requirement forces things like the message being passed to the custom attribute’s constructor (done on your implementation), have to be a constant rather than a static value. This means you are not able to localize the value.
 
When you are doing validation, chances are you are going to want to present the user with the validation message at soe point. You can get around this by putting in unique message codes into the constructors and then, after validation, mapping the code to a static value that you can get from a resource file. This is kind of a pain, but it will work.
 
Strongly-Typed Validation:
The best example of this is presented on JP Boodhoo’s blog. Another example that I have come across is a Java sample that is simple enough to port to .NET if you were to go through the sample (like I did).
 
I won’t go through an implementation of these, the code is available to read on those sites.
 
Pros:
Strongly-typing validation is very nice and an excellent application of generics.
Being that they are simply classes used in a strategy pattern, you can utilize static values and localize the values you will likely be using to ultimately send back to the end user.
 
Cons:
You can’t use inheritance to quickly assemble the rule-sets for inherited objects. This makes building rule-sets for inherited objects a bit of a pain.
 
Object Typing Validation:
This style of validation creates a type for each value so that it is unable to accept invalid values. I have an example of this that I posted on my blog in February 2006.
 
Pros:
This is likely the most OOP method of doing validation on an object property. It simply only permits valid information to be entered and you would, then, only have to put in business logic type validation after the values have been set. You can use inheritance to build on existing types and rules.
 
Cons:
This method is a bucket-load of work to create a volume of types usable within your application and would likely be difficult to create a volume that is generic enough to be applied to applications other than the one you are working on.
 
One other issue with this style of object validation is that each time you set a property, you have to wrap it in a try/catch block (though with some re-design, this may not be the case).
 
Conclusion:
So, the real question is, what’s the "best" validation to perform. I think it really depends on what works best with the application you are working with. Of all of them, I am most happy with Strongly-Typed validation, though I think it’s limitations are kind of a pain.
 
This post is timely as I read a recent post by Donald Belcham regarding work he’s been doing with Custom Attribute style validation. I recently ditched my own implementation within the prototype, we tried to implement the strongly-typed validation and were unhappy with it. Over this weekend I have been working on designing a hybrid solution that should help solve a number of the problems of each of the solutions outlined. I’ll post what I’ve come up with later on this coming week and the debate can continue.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s