ZenArchitect.NL (Henk van Dijken)

Tweet

Sometimes, you want to do some simple validation. For example, data should not exceed the reserved storage size for the field in the database.

In this example CustomerName must be less than 10 characters. So, the client code should look like this:

Customer customer = new Customer();

// customer name must be less than 10 characters
customer.CustomerName = this.textBox1.Text;

// Validation facade
ValidationResults results = Validation.Validate<Customer>(customer);

// populate listbox with validation results
foreach (ValidationResult result in results)
{
    this.listBox1.Items.Add(result.Message);
}

The customer name is filled with input from a textbox. The complete customer object is validated using a validation facade. Finally, a list box is populated with the validation results.

Use of a facade simplifies use of validation in the client. The facade itself looks like this:

public static class Validation
{
    public static ValidationResults Validate<T>(T validationobject)
    {
        Validator<T> validator = ValidationFactory.CreateValidator<T>();
        ValidationResults results = validator.Validate(validationobject);

        return results;
    }
}

But wait! This looks exactly like the Validation Application Block. That’s a coincidence!

Indeed. Since the callings are similar you easily can replace the plumbing with the real stuff later on if you want.

But be aware that there is a small difference. This simplified version does not use attributes, but self validation by implementing an ISelfValidation interface.

public interface ISelfValidation
{
    void Validate(ValidationResults results);
}

The object in question implements ISelfValidation as follows:

class Customer : ISelfValidation
{
    public string CustomerName { get; set; }

    public void Validate(ValidationResults results)
    {
        int maxLength = 10;
        string validationString = CustomerName;

        ValidateStringLength(results, validationString, maxLength);
    }

    // this can be put into a helper class if you want
    private static void ValidateStringLength(ValidationResults results, string validationstring, int maxlength)
    {
        if (validationstring.Length > maxlength)
        {
            results.Add(new ValidationResult(String.Format("Length must be less than {0}", maxlength)));
        }
    }
}

This way simple validation becomes very easy. So, kids please do try this at home.

Download(s) : [Download not found]

Tweet

Validation of user input is very important. A lot of our users are very environmentally aware and throw all kinds of garbage in (= garbage out). So you probably better use extensive validation for all your dataclasses (or Business Entities, if you like).  A consequence is that you have to invoke validation almost everywhere in your business logic. That’s a lot of boooooring repetitive work.

To me this smells like a cross-cutting ‘AOP’ concern, i.e. use Policy Injection.

In the following example of validation “the AOP way” I show you how to use Validation with Policy Injection, which are both part of Enterprise Library.

For simplicity we are going to validate a very simple Customer class, which still is very realistic. Even in the real world you can come across some really simple customers, like this one:

“I do not want to pay a penny extra for validation. When I buy me an application I expect that you deliver one fully validated without errors in it. So if you want validation, please do it at your own expense.”

Yes, this customer is in heavily need of managing customer expectation, but that’s a different story.

The how-to example is build around a Factory Design pattern (Customer, interface IRepository, and concrete class CustomerRepository) and accessed via Facade pattern (CustomerManager). I use a facade here, because then you do not not have to reference parts of Enterprise Library in your client code. Enterprise Library can stay within a single class library together with the other stuff. Isolation of the chosen technical implementation. In this way we can easily replace it with a better implementation, if we don’t like Policy Injection any more.

public class Customer
{
    string m_FullName;

    [StringLengthValidator(5)]
    public string FullName
    {
        get { return m_FullName; }
        set { m_FullName = value; }
    }
}

The property FullName is decorated with a validation attribute StringLengthValidator. Upon validation it is checked if the length of the string does not exceed 5. I know, silly validation.

The client code is as follows, it just calls the CustomerManager facade:

CustomerManager mgr = new CustomerManager();

Customer customer = new Customer();
customer.FullName = "thisisaverylongname";

bool IsValid = mgr.Save(customer);

The CustomerManager façade:

    public bool Save(Customer customer)
    {
        bool IsValid = false;

        IRepository ctr = PolicyInjection.Create();
        try
        {
            ctr.Save(customer);

            IsValid = true;
        }
        catch (ArgumentValidationException ex)
        {
            ValidationResults results = ex.ValidationResults;
            // ...
        }

        return IsValid;
    }

Finally, the interface IRepository and its concrete class CustomerRepository:

//IRepository interface:
interface IRepository
{
	[ValidationCallHandler]
	void Save(Customer customer);
}

class CustomerRepository : IRepository
{
	void IRepository.Save(Customer customer)
	{
		// Saving logic...
	}
}

With this concrete example at hand you should have a start of and be able to experiment a little bit with validation the AOP way.

If you need some extra help with the above example or have a strong opinion towards use of the Policy Injection, just leave a comment.