Подход для передачи результата проверки при сбое от службы 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

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

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