One of the nice features of Silverlight with RIA services – one of the things I really dig – is how easy it is to perform data validation. This is how I have always imagined data validation should work. It’s simple and segregated and looks damn pretty on the screen. I don’t have to write any special code on the client to make the validation happen, I just call my service and tell it to persist my object and it lets my user know – via some very nice UI graphics – if there’s a problem with the data.
I can write complex server-side validation code that queries against a database or I can even write validation code that checks against combinations of properties on the object in question. This is good stuff.
That said, validating data that comes from a ComboBox can be a bit confusing, at least initially.
Validating something like a string property on an object is straightforward. You’re dealing with one property on the object and one simple binding (like a TextBox) on the client. If the data is invalid, you’re going to inform the Silverlight’s validation mechanism by way of a ValidationResult, telling it which property on the object was in error. Silverlight takes care of the rest.
But ComboBox data can be slightly less straight forward when you’re dealing with child objects that are referenced by the parent via a foreign key. Typically we’re talking about a lookup scenario – data that is stored in lookup tables and we’re trying to force the user to choose from a set of available values. Now you have two pieces of data on your parent object that matter: the child object itself and the foreign key.
Here we have two child objects: Genre and Studio. Each are associated to the parent object, Movie, by way of their keys. Also on the parent object are references to the actual child objects themselves. These objects are simple, but the reality is they can (and may) be much more complicated child objects.
public partial class Movie
{
public int MovieId { get; set; }
public string Title { get; set; }
public int YearReleased { get; set; }
public int GenreId { get; set; }
public Genre Genre { get; set; }
public int StudioId { get; set; }
public Studio Studio { get; set; }
}
When you query for a Movie object from your service you’re going to get those child objects attached to the parent, and then you can use their data for databinding.
The tricky part here is that each piece of data (the child object and the key) is important for different reasons, and you’re going to use both. The foreign key is important because that’s what you want to actually validate against – you want to make sure the value actually exists in the database. We’re going to do that server-side with a validation class.
public class MovieValidator
{
public static ValidationResult ValidateHasGenre(int genreId, ValidationContext context)
{
var service = new MovieService();
var genre = service.GetGenres().Where(x => x.GenreId == genreId).SingleOrDefault();
if (genre != null) return ValidationResult.Success;
return new ValidationResult("Must select a Genre", new[] {"Genre"});
}
public static ValidationResult ValidateHasStudio(int studioId, ValidationContext context)
{
var service = new MovieService();
var studio = service.GetStudios().Where(x => x.StudioId == studioId).SingleOrDefault();
if (studio != null) return ValidationResult.Success;
return new ValidationResult("Must select a Studio", new[] {"Studio"});
}
}
The reason we need to validate against the foreign key is because RIA will not send the actual child object back across the wire when you try and persist the parent object. If you check the values of the Genre and Studio properties on the Movie object when it gets sent to the server, you’ll notice they are both null. That’s because RIA knows that the only piece of information that’s actually important to the parent object is the key. This is by design so that RIA sends less data over the wire.
However, when we want to inform the client that the value is invalid, we don’t want to tell the client that the key is invalid because the key isn’t bound to anything on the screen. What we want to give Silverlight is the same name as the property that the ComboBox is bound to. In this case, the Studio or Genre properties.
This is why, when the validation fails, we send back the correct property name as the second parameter on our ValidationResult:
return new ValidationResult("Must select a Genre", new[] {"Genre"});
By doing this, Silverlight will be able to find the appropriate binding on the UI and mark it as invalid. We get the pretty red border and mouseover text telling us that we have to choose something from the ComboBox.
This isn’t anything terribly difficult, it just may not be immediately intuitive the first time you try and validate the data and don’t get the expected red border around the ComboBox.
Source code can be found here
