views:

338

answers:

0

I am looking for information on how people are handling business rule (and field validations) using an ADO.NET Data Service wrapped around an Entity Framework object context.

I have seen numerous posts/articles/etc that seem to be fine with just throwing an exception. I would prefer to have an object that contains a set of errors with additional information like the Field or Model that didn't pass validation. Initially I was hoping to just throw a FaultException with my own serializable objects during the Context.SaveChanges virtual.

throw new FaultException(listOfErrors, "Validations Failed");

The problem I have though is that the ADO.NET Data Service will only give back a DataServiceException. Inside of the DataServiceException I can see that the Response property does have a ChangeOperationResponse but unfortunately the only information I can get out of it is:

An error occurred while processing this request. Validations Failed System.ServiceModel.FaultException`1[[MyNameSpace.MyListOfErrors, MyNameSpace, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]] ...stack trace here...

Why is this inconsistent with the WCF standard of preferring Faults to be passed back over the wire? Does anyone know of an alternative rather than implementing my own CRUD services (plus everything else the service gives us, filter, sort etc)?