Дизайн WCF - один объект запроса и ответа или несколько?

Question

Должны ли вы создавать по одному объекту запроса / ответа для каждого метода или один для каждого сервиса?

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

Объект ответа будет иметь только словарь, bool, int, представляющий идентификатор, и строковое значение для имени.Я не уверен, что вижу смысл в создании группы отдельных объектов, которые имеют внутри одинаковые вещи, а не просто используют один объект.

Что считается наилучшей практикой?

Answer 1

Я согласен с ответом Ника Райана. За подробностями обращайтесь к блогу, который я написал некоторое время назад http://www.link -intersystems.com / blog / 2012/01/12 / design-and-cons-of-service-layer-designs /

Answer 2

Я бы посоветовал один для каждого метода, содержащий только информацию о запросах и ответах, которую этот метод предоставляет и возвращает.Причина в том, что для клиентов будет понятнее, каковы ожидания этого метода при создании прокси-кода из wsdl.

Answer 3

ИМО не существует универсального ответа для всех - это зависит

Если у вас есть «контроль» над обоими концами провода (т. Е. Ваш собственный клиент .NET является единственным потребителемСлужбы WCF), тогда имеет смысл общий тип (т. Е. Повторное использование одних и тех же сборок сущностей на клиенте и сервере).Если вы сделаете это, то наличие общего набора сущностей, которые совместно используются всеми службами в вашем проекте, сэкономит время на повторное изобретение колеса (например, для кодов результатов, информации о нумерации страниц, дополнительной пользовательской контекстной информации и т. Д.).Вы также можете использовать сгенерированные ссылки на сервисы или напрямую использовать ClientBase <> в своем клиенте с общими интерфейсами ServiceContract.В этом случае вам на самом деле не все равно, как выглядят данные по сети, если они корректно сериализуются / десериализуются.

Однако, если есть другие не .NET-потребители вашего WCFКроме того, существуют другие соображения.

DataContractSerializer создает схему запроса и ответа для каждого метода (обычно это Method и MethodResponse) с подписью метода, выставленной на обоих (включая имена переменных параметров).От технологии отображения WSDL клиента будет зависеть то, будут ли общие объекты в запросе и ответе «свернуты» в повторно используемые объекты или будут ли создаваться новые объекты каждый раз.

При использовании DCS нет 'давление ', чтобы обернуть несвязанные поля / параметры в один класс - например, ваша подпись сообщения может быть

public DoSomethingResult DoSomething(int parameter1, SomeEntity parameter2, string parameter3);

Вы также можете рассмотреть MessageContracts .Это «заставляет» вас задуматься о том, как данные выглядят по сети, а запросы и ответы содержатся в объектах-оболочках.IMO MessageContracts хорошо работает в сценариях EAI (например, если у вас есть клиент BizTalk), поскольку распространенное ответное сообщение, которое, как вы предлагаете, может быть повторно использовано в нескольких вызовах службы.

HTH