Microsoft | patterns & practices | Developer Network | Enterprise Library | Acceptance Testing Guide | Personal Site
As we are spiking on the EntLib Silverlight Integration Pack, we can use some feedback on the validation story. With the recent addition of DataAnnotations and RIA Services to the framework stack, we would like to avoid adding confusion to the Silverlight platform by introducing yet another validation framework. At the same time, we’d like to provide a cross-platform validation solution.
We are contemplating 2 options here:
Porting the existing Validation Block gives the advantage of letting users take code and configuration that currently uses it and bringing it across unchanged to a Silverlight app. No new learning is required if you already know VAB.
However, with the recent improvements in the DataAnnotations validation and the RIA services additions, many of the scenarios that were originally supported only by VAB are now also addressed by the Silverlight / RIA services platform. If we were to instead provide a way to address those scenarios that are not currently there (primarily around config driven validation and validation rule sets), we could have a much smaller download, and better consistency with the rest of the Silverlight platform going forward. The downside is that code changes would be required to existing validation code that uses VAB.
The fundamental question becomes how important it is to have code/config sharing for validation between desktop and Silverlight apps? Is it acceptable to make code changes in your desktop apps for validation to get the validation work in Silverlight? Or is it essential that the validation attributes and configuration come across unchanged from a desktop/server app using VAB into your Silverlight clients?
Go with the DataAnnotations. I strongly believe the Rest of the Framework will catch up in terms of validation via Annotaions. So code sharing will be becomming possible again.
This is a no brainer for me (currently working on a SL4 RIA Services project) -- do the validation that is right for the platform -- RIA Services, DataAnnotations, INotifyDataError, etc.
When you are doing it, consider async in C#5 as well.
Go with a full port of the validation block. If we are using the validation block at the service/domain levels we would want to share the same validation code at the client level with little to no changes. Not everyone is using RIA Services (as of my last check RIA Services does not play well with WPF) and if we are using RIA Services we would use the validation baked in that portion of the framework. The validation block is probally the most applicable block of entlib to share with Silverlight as good design says to validate at the client and at the server.
I am not married one way or another but I would personally prefer that scenarios like configuration driven validation, validation rule sets and dynamic context based rule evaluation would be integrated directly in Ria Services since we have a huge investment made there. I am actually crafting a solution right now for our Ria Services based framework and I would have really liked it if that would be ready out of the box.
I'm currently very entrenched in PRISM development, utilizing the Multi-Targeting development approach where I share code between WPF and Silverlight. I use a modified version of the NetTiers templates with custom Silverlight entities and are able to easily work between WPF and Silverlight using the same back end. My biggest problem thus far has been common support for validation between the two frameworks.
From my point of view, the port of VAB would be the best solution, since this will allow me to apply validation which will work on both platforms without having to deviate any code to be platform specific.
That being said, however, the Data Annotations offer a very rich and cool way of dealing with validation, it is just too bad that they don't work on WPF (yet). Maybe a 3rd option would be to initially just port the VAB to Silverlight, and then to upgrade both VAB's to be more inline with the Data Annotations way of doing things. This would be especially handy if/when WPF gets Data Annotations.