Подход к результату проверки валидации, при сбое, от службы WCF (с обработкой данных EF4) клиенту MVC3

Question

Я реализую приложение ASP.NET MVC3, к которому осуществляется доступ к данным через службы WCF. Служба WCF использует EF4.1 для доступа к данным с классами DBContext и POCO для объектов. Я могу аннотировать свойства с атрибутами проверки данных на стороне сервера, а также я могу реализовать выборочную проверку, определяя либо пользовательские атрибуты проверки (полученные от ValidationAttribute), либо путем реализации IValidatableObject).

Но у меня есть проблема: если проверка не удалась, что лучше всего подходит для передачи информации об ошибке проверки с WCF клиенту, а затем использовать ее в клиенте MCV3?

Как я понимаю, с WCF все данные, обмен которыми осуществляется между клиентом и WC-службой, должны быть частью контракта с данными и не должны использовать исключения как способы передачи значимой информации между сервером и клиентом (например, сбрасывание проверки ValidationException с добавлением дополнительных свойств для информации об ошибке валидации).

Также в WCF, который использует EF, я вызываю dbContext.SaveData(), но если данные недействительны, это вызывает исключение, которое я не хочу.

Итак:

1. как я могу назвать проверку явно в EF и убедитесь, что либо объект является действительным, и я могу назвать SaveData(), или объект является недействительным, и я могу собрать как-то информацию ошибок валидации перейти к клиенту.

2. Я могу передать эту информацию об отказе от валидации обратно клиенту, как часть контракта данных, а не исключение.

Благодаря

Answer 1

Вы можете использовать два подхода:

• Используйте стандартный контракт данных ответа на успех и fault contract с FaultException<YourFaultContract> для отказа проверки. Типизированные исключения ошибок - это способ определения «ожидаемых» исключений - это просто другой договор данных, переданный в SOAP Fault, описывающий некоторый сбой.
• Создайте контракт на получение ответа, который содержит что-то вроде результирующего кода, данных ответа, сообщения об отказах и т. Д. И использует этот контракт данных как для успеха, так и для отказа. Мне не нравится этот подход, но его проще использовать в некоторых ESB, где ошибки обрабатываются особым образом.