views:

732

answers:

2

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.

+2  A: 

If you throw an exception in the setter, then IDataErrorInfo is redundant since it can't (in theory) get into an illegal state. IDataErrorInfo allows 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 .Error from your business logic (and check that it is null/empty), assuming that you write .Error to report all errors. Or a similar Validate() method.

Marc Gravell
Isn't against OO principles to have wrong value in the object? This is what make me a little suspicious by validating in a later stage. A wrong value could have impact on other functions of the object even if the object is not saved...
Daok
As long as your object makes it clear that it allows such data and provides a mechanism for validation, I don't think it violates anything.
Marc Gravell
+1  A: 

I believe that the IDataError allows for a much richer user experience. Like Marc said, it allows less interruption, especially when editing a grid eg. a list of Customer objects.

I recommend you download the CSLA.net framework from www.lhotka.net, developed by Rocky Lhotka (He is the author of Expert C# 2008 Business Objects). This framework supports validation rules and each business object implements the IDataError. Each time a property is changed, the rules for that property are validated. If the property value is invalid, the object state will become InValid, causing a exception to be thrown whenever the Save() method is invoked.

His framework also supports n-level undo. When you start editing a business object, a snapshot of the object is taken (including the broken rules). So if you decide to rollback your changes, the state of the object returns to the previous state - even the broken rules!

MegaByte