Over the weekend Sacha published a new article on codeproject, Total View Validation (does Sacha ever sleep?). This article addresses some of the perceived problems with the WPF binding framework, firstly, that the standard solution of using the ValidatesOnDataErrors property forces you to place validation logic into your bound business objects, and secondly, that there is no way to perform validation across multiple objects. His solution to both these problems was to construct a view model which contains the validation rules and applies them to all the objects within the form. A collection of validation failures are associated with the view model. These can either be rendered in their entirety or each control within the view can render errors relating to their context.
This blog post describes how BindingGroups can be used to address the problem of applying validation rules to multiple objects.
BindingGroups were introduced as part of .NET 3.5 SP1, Vincent Sibal provides a good introduction to this new features on his blog. I have previously blogged on the subject of BindingGroups, where I demonstrated how they can be used to provide improved error messages when type conversion fails during the binding process.
In this post I will take the application from Sacha's article and modify it to use BindingGroups. The following is a screenshot of the application:
The form displays the details of two People (two instances of the Person class). The user inputs data using the above controls then clicks the Validate button to run all the Form's validation rules. Most of the validation rules relate to a single property of the bound object, e.g. FullName cannot be empty. However there is one trick validation rule:
"If Person 1's age is less than 18, Person 2's age cannot be zero"
This rule cannot be evaluated by assocaiting it with the Age property of either person. It requires access to both Person instances, hence it really belongs at the scope of the form itself. This is where BindingGroups come in ...
The XAML below shows our form which consists of a pair of StackPanels that contain fields bound to our Person instances by setting their DataContext properties in the code-behind. The 'root' element of the Window contains our BindingGroup.
Rules associated with a BindingGroup have access to both their associated binding expressions, and the source objects used by these bindings. A BindingGroup becomes associated with a collection of binding expressions if it shares the same DataContext. However, in the above example we have a pair of objects, therefore we cannot share a DataContext across all the elements in our XAML (this is not strictly true, we could construct a view model for this purpose, however I really want to illustrate one of the other features of BindingGroups). BindingGroups can also be explicitly associated with a Binding via its BindingGroupName property.
So just what exactly can we do with our BindingGroup? It is possible to execute this rule at various different steps of the binding process, for example, it is possible to evaluate the rule before type conversion has occurred. In this instance, we are only interested in the converted value, hence the ValidationStep property is set to CommittedValue. The rule itself is very simple:
We simply retrieve both Person instances, apply our rule raising an error if our condition is not met. Any validation errors returned by the BindingGroup become associated with the Validation.Errors attached property of the element which the BindingGroup is associated with. Therefore they can be accessed and styled in the 'standard' way, for example:
See the excellent article Validation in WPF for details.
However, BindingGroups offer one further advantage, validation errors from the associated binding expressions are also placed in the Validation.Errors collection, therefore we can output all the validation errors for our form by binding to this property as follows:
The following screenshot shows the form where multiple validation errors are present:
So ... which approach is better? BindingGroups or Sacha's ViewModel technique?
Personally, I don't think there is one best approach - and this blog post is certainly not an attack on Sacha's article, which presents an elegant solution. My intention is to simply show that it is possible to perform validation on multiple objects at a 'wider' scope with the standard WPF framework.
To quote Mike Hillberg, the Poo is Optional.
A sample project with the code from this post is available for download: bindinggroupsglobalvalidation.zip.
Regards, Colin E.