Oct 29, 2010 (08:10 PM EDT)
Silverlight's Validation Fix
Read the Original Article at InformationWeek
Data validation--the process of guaranteeing to an application that every data value is accurate--is a crucial part of any application. But for developers using Microsoft Silverlight, this has been a problem: There wasn't a good way to ensure that data, such as a user ID or e-mail address, is entered correctly.
That's changed with Silverlight 4, thankfully.
Before now, the typical way of validating data was to throw exceptions within property-setter blocks when data was invalid. Controls bound to a property could be notified of a data validation exception by setting ValidatesOnExceptions to True in the data binding. While this works, Silverlight 4's IDataErrorInfo provides a better way to validate data.
Let's start with IDataErrorInfo's members. The IDataErrorInfo interface contains two members, including Error, which can return error information about the overall object, and a default indexer property that can be used to write validation logic for different properties within an object. You implement the IDataErrorInfo interface on a client-side entity class in your Silverlight project. When the Error property isn't used--often the case--you can simply return null.
The bulk of validation work is done in the default indexer property. It's called by controls that are bound to object properties as data changes to see if a particular bound property is valid or not. Assume your code has two basic properties in it that need to be validated. This can be done in the default indexer property added into the class as a result of implementing IDataErrorInfo as in this code. (See code in box.)
The validation operations performed in the default indexer property are often straightforward. For example, a switch statement can check which property needs to be validated. From there, each case statement is used to perform validation logic, including checking that the Name property isn't null or empty and that the Age property has a value greater than zero.
What's nice about this approach is that the validation logic is put in one place and, in more real-world situations, the logic can even be moved to an external validation object that provides some reuseable methods to check for null strings, check string lengths, validate numeric ranges, etc.
The end result of implementing the IDataErrorInfo interface is that controls bound to properties can check to see if data is valid or not and then display an error message as appropriate. This is done by adding the ValidatesOnDataErrors property to the data binding.
The downside of IDataErrorInfo is that it doesn't perform asynchronous validation. In some situations, you may need to call back to a server to check that a user ID or e-mail address is unique within the system or that a tax code matches an existing code stored in a database. IDataErrorInfo doesn't support this type of scenario directly.
Dan Wahlin is a Microsoft MVP and Silverlight consultant. You can write to us at firstname.lastname@example.org.