Since I am trying to learn WPF I see more and more the use of the interface IDataErrorInfo to bind the error to the interface. My problem is that I usually put the validation of the data in the setter of the property and not in a method like IDataErrorInfo.this[string columnName]… Here is a blog I have found that have make me confuse.
What is the good way to proceed in .Net 3.5 to validate data object? Do I need to implement validations in method called by the Setter AND the IDataErrorInfo? Or just the IDataErrorInfo? Or in the setter call the IDataErrorInfo?
Example: I have a firstname string that can have only 3 to 50 chars. Do I put the string validation in the setter (What I would do usually) or now I can simply use the IDataErrorINfo.this method, check the property name and return a String Error when the data is not the good length? I found more intuitive to throw an error in the setter and not using the Interface but most example I see use the IDataErrorInfo interface.
If you throw an exception in the setter, then
IDataErrorInfois redundant since it can’t (in theory) get into an illegal state.IDataErrorInfoallows you to accept all input, but tell the user that there is a problem. The nice thing about this is that it allows less interruption to the UI (as the user can continue to enter data even though one field is in error and marked as such), and it is easy to report multiple errors at once – visually, rather than by message-boxes etc.However, if you go this route you need to be sure to validate that the object is OK before saving it to a database, etc.
You could do this by checking
.Errorfrom your business logic (and check that it isnull/empty), assuming that you write.Errorto report all errors. Or a similarValidate()method.