This is the first of 3/4 posts about the implementation of the UI Validation in a Windows Form application using the MVP Pattern.

In order to be able to follow my article you must have and know:

1. Microsoft Enterprise Library UI Validation, available at this link.
2. Basic knowledge of the MVP pattern.

Analysis.

First of all I want to explain why I’m going to validate the domain and not the UI. The concept is that a validation represent a constraint on the data. In most of the case the UI layer is never fixed and stable, but for the domain, at most, we have to change a field or an entity, so less effort.

Second point, why I should contact a DAL layer and validate the entity if I can do it before and save some bandwidth and resources??

If we add the validation in the domain, in the future, we will be able to carry our domain everywhere without tacking care of problem like the validation. If we add the validation in the UI, our presentation layer will be strictly connected to our domain, and this is something we don’t want.

The basic object.

One of the most helpful technique in the OOP (object oriented programming) is the inheritance. We can build a basic class with some useful methods and properties and use it like a contract for the other inherited classes.

In our case we want to build a simple domain object class that will represent all the instances of our domain.

Let’s view the simple code to build this class.

   1: using System;

   2: using System.Collections.Generic;

   3: using Microsoft.Practices.EnterpriseLibrary.Validation;

   4: using Microsoft.Practices.EnterpriseLibrary.Validation.Validators;

   5:  

   6: namespace XXX.Core

   7: {

   8:     public abstract class DomainObject

   9:     {

  10:         private ValidationResults Validate()

  11:         {

  12:             Validator validator = ValidationFactory.CreateValidator(Type.GetType(this.ToString()));

  13:             ValidationResults errors = validator.Validate(this);

  14:             IList<string> list = new List<string>();

  15:             foreach (ValidationResult result in errors)

  16:             {

  17:                 list.Add(result.Message);

  18:             }

  19:             this.ListResults = list;

  20:             return errors;

  21:         }

  22:         public virtual bool IsValid()

  23:         {

  24:             return this.Validate().IsValid;

  25:         }

  26:         public virtual IList<string> ListResults

  27:         {

  28:             get;

  29:             private set;

  30:         }

  31:     }

  32: }

I have just create the set methods as private because I don’t want to modify them outside the domain object class. Of course anyone of you will have a different solution here. I must use virtual because I hardly use the NHibernate Proxy.

At this point we have just to inherit from this class, any entity of our domain, also the entities that should not be persisted. Why? Because the validation we are going to do now it’s very straightforward. Then decorate the entity with some attributes.

Note: I don’t know why and I have found a lot of concerns about this solution but actually the Enterprise Library doesn’t have a nice way to implement the inheritance directly and the only way to do that is to use the constructor that uses the reflection:

  12:Validator validator = ValidationFactory.CreateValidator(Type.GetType(this.ToString()));

The entity.

Now let’s build the first entity that will inherit form our domain object. It should be something like that:

   1: namespace XXX.Core.USER

   2: {

   3:     public class User:DomainObject

   4:     {

   5:         ///Class implementation

   6:     }

After that what we need? Of course the fields of our entity! In this case I use the NET Framework 3.5 lazy creation where you don’t have to declare the private accesses.

   1: public virtual int Id { get; set; }

   2: public virtual string Username { get; set; }

   3: public virtual string Password { get; set; }

Now let’s define some business validation rules:

1. Each of these fields cannot be null.
2. The Username cannot be lower than 5 characters and longer then 20.

   1: [NotNullValidator(MessageTemplate="Id cannot be null")]

   2: public virtual int Id { get; set; }

   3:  

   4: [NotNullValidator(MessageTemplate="Username cannot be null")]

   5: [StringLengthValidator(5,20,MessageTemplate="Username has to be from 5 and 20 charactersS")]

   6: public virtual string Username { get; set; }

There we go!

The decoration attributes.

The enterprise library offers a very nice and configurable solution for the UI validation. This list is only a part of them and you can also build custom group of validation rules.

• ContainsCharactersValidator - Performs validation on strings by verifying if it contains a character set.
• DateTimeRangeValidator - Performs validation on DateTime instances by comparing them to the specified boundaries.
• NotNullValidator - Logs a failure when validating a nullNothingnullptr reference.
• RangeValidator - Performs validation on T instances by comparing them to the specified boundaries.
• RegexValidator - Performs validation on strings by matching them to a Regex.
• StringLengthValidator - Performs validation on strings by comparing their lengths to the specified boundaries.

The next post will show you how to integrate this Framework (If we can call him a framework …) with the Presentation Layer.