I was curious about the client side... You use a DomainDataSource class in you xaml or a DomainContext in mvvm?
If your are using DDS than don't do that
You have a Submit method in your viewmodel, which calls SubmitChanges... In this method before you call submitchanges call your validation logic.
Now about the validation logic... on the client side you don't have metadata classes... that exists only on the server side... on the client side the attributes are placed over the properties of the original entitiy.
Now you have the validateproperty method in the viewmodel. Override it... See the code I posted on my blog for the session and rewrite that part where I use Validator.TryValidateProperty(this.....) instead of "this" you should add the ria entitiy you want to validate...
After the talk we had a discussion on it I you can definitely change this architecture to be used by the model, and wire it up to the viewmodel... I even mentioned a way, where you just have to override the ValidateProperty method and modify it to use the validator on the model itself and not on the viewmodel... i think this one is the easyiest way.... Your approach works as well perfectly.
Anyway I agree with you, data should be stored in the model, but it's kind of up to preference (since you can statically codegen your viewmodels ). You have one thing to make sure, the viewmodel has to know, if there is something worng with the model... if you can stick to that, you are good to go
Yeah, well you could definitely wire it up to handle these kind of scenarios as well. You just have to find a way to indicite the error back to the client and call AddError, and there you go... the infrastructure is already there. However I wouldn't mix exceptions into validation mechanism... that's something different semantically for me... But you could definitely do that.