IDataErrorInfo – is there really any point?

When looking into data validation systems that focus around WinForms and WPF technologies the IDataErrorInfo interface is a common focus. Personally I’ve never been satisfied with this interface. Not only does it appear to have some very poorly named members, it just doesn’t seem anywhere near functional enough. Don’t get me wrong – its a great concept – it just seems to be a super-lightweight example.

From MetaData on IDataErrorInfo:

   // Summary:
  
//     Provides the functionality to offer custom error information that a user
  
//     interface can bind to.
    public interface
IDataErrorInfo
    {
      
// Summary:
      
//     Gets an error message indicating what is wrong with this object.
      
//
      
// Returns:
      
//     An error message indicating what is wrong with this object. The default is
      
//     an empty string ("&quot.
        string Error { get; }

       // Summary:
      
//     Gets the error message for the property with the given name.
      
//
      
// Parameters:
      
//   columnName:
      
//     The name of the property whose error message to get.
      
//
      
// Returns:
      
//     The error message for the property. The default is an empty string ("&quot.
        string this[string columnName] { get; }

    }

So if I have a business object, Contact, that implements IDataErrorInfo then to get a description of the validation state for a particular property we use myContact[propertyName]. That really doesn’t seem very intuitive, surely that should be a method call, e.g. myContact.GetPropertyValidationState(propertyName)? Of course because all the return results are strings rather than object there’s no clean path for extensibility here either.

Does anyone really use this interface for anything other that quick data-binding sample applications? Really – I’d love to know.

Paul’s latest foray into a WPF Validation framework got me started on this. Though to be fair his draft framework has clear extensibility points for plugging in a much richer business object validation interface.

3 thoughts on “IDataErrorInfo – is there really any point?”

  1. We use IDataErrorInfo here, but we never explicitly use the this[propertyName] syntax. That’s handy for WPF/WinForms error handling (showing that the TextBox itself is in an error state), but from our code we always inspect the Error property, which we implement thusly:

    public string Error
    {
    get { return this[“Foo”] ?? this[“Bar”] ?? this[“Fizz”] ?? this[“Bang”]; }
    }

    … so the Error property is non-null if any column has an error.

  2. All WinForms apps I’ve done lately (and they are definitely much more than sample/demo apps) use databinding to view model objects implementing IDataErrorInfo and an ErrorProvider on the form. Works great.

Comments are closed.