I had been using IDataErrorInfo implementations in all of my view models when writing WPF apps in order to perform property validation for the view. It's worked really well, with a couple of exceptions.
- Sticking it in my view models usually results in a really long indexer, as I perform validation on all of the properties in my view model.
- Prevents the validation from being re-used across multiple view models. While in some cases, validation is view specific, there are certainly times were validation is object specific (and not view specific), in which I could re-use it in multiple places.
We have made it roughly 50% of the way through our app at work when I ran across a post on MSDN Social that essentially clarified things for me. Unfortunately, it means a pretty heft change to our overall app and I don't know if the time required to migrate all of the object level validation down to the models right now is justifiable. At some point I really think we should make the change, since it would probably help make things easier to trace in the future during debugging.
Having all of the validation contained within the model makes sense. You could then use the CanExecute method in the ICommand to ensure business rules are met prior to allowing actions to take place. Other business rules related to a combination of values could be applied within the view model, either using an implementation of IDataErrorInfo or a child of ValidationRule.
So my lesson learned for the day is, validation in POCO classes are alright, and in most cases encouraged.