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:
- Microsoft Enterprise Library UI Validation, available at this link.
- Basic knowledge of the MVP pattern.
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.
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()));
Now letâ€™s build the first entity that will inherit form our domain object. It should be something like that:
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.
Now letâ€™s define some business validation rules:
- Each of these fields cannot be null.
- The Username cannot be lower than 5 characters and longer then 20.
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.