Validation

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The latest Enterprise Library information can be found at the Enterprise Library site.

On this page:
Validation in a Silverlight Application

Validation is a very important aspect of any line of business (LOB) application. A good validation implementation helps prevent data corruption and enforces compliance with business rules.

Microsoft® Silverlight® allows you to build applications that provide a rich user experience, and part of a rich experience is good validation. When a validation error occurs, the user should get clear and obvious feedback as quickly as possible so he is not left wondering what is happening. Simple validation checks might be performed as the user is typing, or more complex validation rules might be run in the background while the user is still performing some task. Validation error messages should provide a clear description of the cause of the error, with an indication of how the user can solve the problem.

In this chapter, we'll examine the most common validation scenarios for Silverlight LOB applications and how the Validation Application Block from the Enterprise Library 5.0 Silverlight Integration Pack can help you implement those scenarios in your application. We'll also discuss how the Validation Application Block can be applied to a Windows® Communication Foundation (WCF) Data Services application and how you can use the Validation Application Block to extend the validation support provided by WCF RIA Services.

Validation in a Silverlight Application

A Silverlight LOB application typically consists of a Silverlight client that communicates with web services to read or modify data in data sources such as databases. As the data flows through the user interface all the way to the data source, there are several places to handle validation. Validation errors that occur in this process will typically flow back to the user interface (UI):

1. The user enters data in a control, for example a TextBox, that is bound to a property on your model. In this context, a model can refer to a View Model from the Model View ViewModel (MVVM) pattern, but also to an entity class generated by WCF RIA Services or a custom business entity. When the user leaves the TextBox, the Silverlight data binding engine will attempt to convert the value in the TextBox to the type of the property and update the model. If the value in the TextBox cannot be converted to the type of bound property, then the data binding engine will throw an exception. You can then use an error style to display an error message.

   Sharon Says:
   	This is such a great feature from Silverlight data binding. In other technologies, such as ASP.NET web forms or Windows Forms, this is much harder. In those technologies you have to manually perform data binding and type conversion, which is tedious work and often error prone.

   2. A rudimentary set of validation rules can be called as soon as the model is updated. For example, you can check if the value falls within certain bounds or fits a specific pattern such as an email address or telephone number. When such a validation error occurs, the model will inform the UI that a validation error has occurred. This can be done by raising an exception that will be handled by the data binding engine or by implementing **IDataErrorInfo**. However, a more flexible approach is to implement **INotifyDataErrorInfo** on the model and raise the **ErrorsChanged** event. 3. When the user is finished entering all information and is ready to submit, some more complex validation rules can be executed. Typically, these are validation rules that span multiple properties or check against reference data. Again, if a validation error has occurred, the UI has to be notified. Throwing an exception in this situation is not an option because the data binding engine cannot catch this exception in that case. For these validation rules, you should implement **INotifyDataErrorInfo** on your model and raise the **ErrorsChanged** event. 4. When there are no validation errors, the data can be submitted to the server. Since validation rules on the client can easily be circumvented, you must run all critical validation rules again on the server. It is also possible that there are additional validation rules that should only be run on the server. Because the web server is typically closer to the data sources (such as the database), you'll be able to do other types of validation checks, such as checking for referential integrity within a transaction. Any validation errors that occur here will also have to be sent back to the client and displayed in the UI. Again, **INotifyDataErrorInfo** can help in this regard.

   Next Topic | Previous Topic | Home

   Last built: July 8, 2011