дизайн архитектуры wcf. Re: вернуть значения - PullRequest
0 голосов
/ 03 мая 2009

Здравствуйте и спасибо за ваше мнение.

Я создаю веб-сервис. Этот веб-сервис будет принимать учетные записи клиентов и клиентов, а также пару других связанных объектов и атрибутов и тому подобное.

Когда веб-служба получает запрос, я пытаюсь его обработать.
Если ошибки нет, я просто возвращаюсь. Если есть ошибка, я ее выкидываю.

Мне интересно, является ли это лучшим подходом, или мне следует изменить свой дизайн так, чтобы я возвращал bool в качестве ответа или даже создал объект ответа, который может содержать исходный объект запроса плюс статус error, список ошибок (т. е. Missing Fields, Invalid Fields, ext).

Какой метод возврата вы бы включили в свой дизайн?
1) Просто вернитесь, если нет ошибки, выведите ошибку, если ошибка 2) бул успех 3) Объект ответа (содержащий исходный объект запроса и подробные результаты)

Спасибо за любые предложения. Стивен

Ответы [ 3 ]

1 голос
/ 03 мая 2009

Общее правило: если обстоятельства не позволяют успешно выполнить запрос, выведите исключение. Если вы хотите сообщить другую информацию, такую ​​как номер заказа и т. Д., Используйте возвращаемое значение. Как правило, не рекомендуется сигнализировать о полном сбое через логическое возвращаемое значение, которое может быть проигнорировано / не проверено вызывающей стороной.

Теперь, поскольку это служба WCF, используемая внешними источниками, вы должны не просто генерировать исключение - это особенность .NET, а скорее вызывать ошибку SOAP. Вы должны объявлять эти ошибки как часть вашего контракта на обслуживание для каждой операции, которую предлагает ваш сервис, добавив один или несколько атрибутов FaultContract к вашим операциям:

[FaultContract(typeof(MyFault1))]
[FaultContract(typeof(MyFault2))]
[OperationContract]
void MyOperation()

Это можно легко сделать в .NET WCF, выбрасывая FaultException или более конкретное FaultException (универсальный вариант, в котором вы можете указать тип ошибки exakt).

Марк

0 голосов
/ 03 мая 2009

Я бы сказал, что это зависит от «ошибки». Если ошибка связана с проверкой, но ожидается в нормальном ходе событий, например, неверные учетные данные пользователя передаются в службу, которая обеспечивает аутентификацию пользователя, тогда возвращение значения перечисления, которое указывает результат запроса (Успех, Отказ и т. Д.), Вероятно, в порядке. Однако, если ошибка связана с вводом, который не должен происходить при нормальном ходе событий, я бы посоветовал вам сбросить ошибку из операции сервиса. Возникновение ошибки указывает на то, что клиентское приложение содержит ошибку и предоставило информацию, с которой служба не знает, что делать. Вы можете зарегистрировать конкретные договоры о сбоях с помощью операции службы WCF, чтобы клиентское приложение знало, что операция может вызвать одно из нескольких сбоев при определенных обстоятельствах. Клиентское приложение должно предоставлять обработчики исключений для этих сбоев и предпринимать действия в случае их возникновения, в противном случае оно неожиданно завершится.

В качестве основного эмпирического правила я бы сказал, выбрасывать ошибки при исключительных обстоятельствах, например где клиент предоставил входные данные, которые сервисная операция не ожидает получить. Если клиент предоставил информацию, которая неверна, но операция службы запрограммирована на обработку, верните код состояния или информацию в ответном сообщении.

0 голосов
/ 03 мая 2009

Я думаю, что это зависит от того, кто будет использовать эту услугу,

если вы единственный, кто будет использовать эту услугу, я рекомендую вам ничего не возвращать (или исходный запрос) и выдавать исключения, если что-то не так.

если служба предназначена для публичного использования, вы должны возвратить некоторый объект ответа, который будет содержать ошибки, и некоторые другие соответствующие данные.

удачи

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...