Using validation rules – to do or not to do?

In WPF, there are two different approaches for dealing with data validation. On the one hand, we have the UI-based ValidationRule classes, the Validation.Error Attached Event, and the Binding.NotifyOnValidationError and UpdateSourceExceptionFilter properties, and, on the other, we have two code-based validation interfaces.

While the ValidationRule classes and their related validation approach work perfectly well, they are specified in the XAML and, as such, are tied to the UI. Furthermore, when using the ValidationRule classes, we are effectively separating the validation logic from the data Models that they are validating and storing it in a completely different assembly.

When developing a WPF application using the MVVM methodology, we work with data, rather than UI elements, and so we tend to shy away from using the ValidationRule classes and their related validation strategy directly.

Additionally, the NotifyOnValidationError and UpdateSourceExceptionFilter properties of the Binding class also require event or delegate handlers, respectively, and, as we have discovered, we prefer to avoid doing this when using MVVM. Therefore, we will not be looking at this UI-based validation approach in this book, instead focusing on the two code-based validation interfaces.