Decorating types for validation

In my previous post, I spent a lot of time discussing the vaious validation methods I have seen and used out there. One thing I had missed was the link to the Custom Attribute-Style validation model that I had implemented previously. A mentioned in the post, I was unhappy with the results of that style of validation as the validation strings weren’t able to be localized properly. In discussion with Jonas, last evening, he had been in contact with someone working on the Enterprise Library 3.0 – Validation Application Block and they have, apparently, been able to add localizability to that block. I am interested in seeing if they implement some sort of mapping class that maps the constant values to static values.
In any case, the purpose of this post was to complete the task I assigned myself at the end of the previous post, to find a more reasonable validation model. What I came up with was a way to decorate types for validation.
EDIT : Full listing here.
This model of validation solves the following problems I had with the other frameworks I had been looking at:
  • You can add validation to any existing object simply by decorating the type with Validatable<T> in a manner similar to that of Nullable<T>.
  • Validatable types can then be assigned validation rules (that can be re-used by types from other) that are then inherited by child types.
  • Validation methods can retrieve their error messages from resource files (or satelite assemblies) and are, thus, localizable.
  • Validation methods can be strongly typed or made generic.
Here’s a sample of one way this method allows you to add validation to an existing object:


public static class ValidationRules {
    public static void ValueMustbePositive(int value) {
        if (value < 0)

            //Retrieve string value from resource file

            throw new ValidationViolationException("Value must be positive");

Person person = new Person(new Validatable<int>(ValidationRules.ValueMustBePositive), "Jason"); 

public class Person {
    Validatable<int> age;
    Validatable<string> name;
    public Person() : this(default(int), default(string)) { }
    public Person(Validatable<int> age, Validatable<string> name) {
        this.age = age; = name;
    public Validatable<string> Name {
        get { return name; }
    public Validatable<int> Age {
        get { return age; }
Please let me know what you think about this validation method.

5 thoughts on “Decorating types for validation

  1. I like it, especially the flexibility of it. I am writing some similar code today at work and your example is timely!

  2. While I think that this is an okay way to implement validation, I think that it has one major drawback.  Because you’re essentially using a custom data type instead of a the native types you could possibly run into issues with serialization and most definitely you will run into problems with cross platform interaction.  If you create a webservice that exposes a Validateable<int> type, there is the definite possibility that type will not be recognized by any other systems that may subscribe to that webservice.  For what it’s worth to those systems, you might as well have used a Dataset.That said, if you have no interaction with other system, and there is none planned in the foreseeable  future, then this will still work.  My personal taste is that it makes the code a little to verbose, but it’s not unworkable.

  3. Though I haven’t explicitly tested serialization of Validatable<T>, the argument for it not being serializable and usable in different systems is flawed, otherwise you wouldn’t be able to serialize any custom types across the wire. When you generate a class from a wsdl, custom types (such as Dtos or other type primatives [complex types]) generate a schema (either through explicit implementation of IXmlSerializable or ISerializable; or implicitly with the Serializable attribute), allowing other systems to use them. A type such as this should be no less serializable/cross platform-able than Nullable<T>.
    I’ll throw some time to validating its serialization and report back.

  4. I have gone through and tested it. The values of a Validatable<T> object _is_ transfered, but the validation rule is not.I would think that this is a non-issue as you are likely, if you are transfering custom types (a Dto containing a Validatable<T> member), to not be worried about transfering the validation logic across from a client object to a server object (never really a good idea to trust anything being sent to you from a client anyway). If you are using a domain model, you would likely want to do your validation on a domain object rather than on the Dto anyway.. so all that is important, at that point, is retrieving the value from the Dto and doing your validation on the domain object. Any validation that was performed on the Dto (by the client application) is superfluous, from a back-end perspective.

  5. Update: I upgraded
    the project for VS 2K8, added type conversion operators to the
    Validatable decorator, and ReSharper-ed the code to clean it up some
    more. The code and files for can be found here.

Leave a Reply

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

You are commenting using your 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