Структура запроса/ответа при реализации SOA

В каком-то корпоративном проекте (.NET, WCF) я увидел, что все контракты на обслуживание принимают один параметр Request и всегда возвращают Response:

[DataContract]
public class CustomerRequest : RequestBase {
        [DataMember]
        public long Id { get; set; }
}

[DataContract]
public class CustomerResponse : ResponseBase {
        [DataMember]
        public CustomerInfo Customer { get; set; }
}

где RequestBase/ResponseBase содержат общие вещи, такие как ErrorCode, Context и т.д. Тела как методов обслуживания, так и прокси-серверов обернуты в try/catch, поэтому единственный способ проверить наличие ошибок - это смотреть ResponseBase.ErrorCode (это перечисление).

Я хочу знать, как этот метод вызывается и почему он лучше по сравнению с передачей того, что нужно в качестве параметров метода, и с использованием стандартных механизмов передачи/устранения ошибок WCF?

Ответ 1

Образец, о котором вы говорите, основан на разработке контракта First. Тем не менее, не обязательно использовать шаблон блока ошибок в WCF, вы все равно можете сбросить ошибки на клиенте вместо использования блока Error Xml. Блок Error использовался очень долго, и поэтому многие люди привыкли к его использованию. Кроме того, другие разработчики платформы (например, java) не так знакомы с faultExceptions, хотя это отраслевой стандарт.
http://docs.oasis-open.org/wsrf/wsrf-ws_base_faults-1.2-spec-os.pdf

Шаблон Request/Response очень ценен в SOA (Service Oriented Architecture), и я бы рекомендовал использовать его, а не создавать методы, которые принимают параметры и передавать значение или объект. Вы увидите преимущества при создании своих сообщений. Как указывалось ранее, они развивались из First Development Contract, где сначала создавались сообщения с использованием XSD и генерировались ваши классы на основе XSD. Этот процесс использовался в классических веб-сервисах, чтобы гарантировать, что все ваши типы данных будут правильно сериализованы в SOAP. С появлением WCF datacontractserializer более интеллектуальный и знает, как сериализовать типы, которые ранее не были бы правильно сериализованы (например, ArrayLists, List и т.д.).

Преимущества шаблона запроса-ответа:

Вы можете наследовать весь свой запрос и ответы от базовых объектов, где вы можете поддерживать согласованность для общих свойств (например, блок ошибок).
Веб-службы должны по своей природе требовать как можно меньше документации. Этот шаблон позволяет именно это. Возьмем, например, такой метод, как public BusScheduleResponse GetBusScheduleByDateRange(BusDateRangeRequest request);. Клиент будет знать по умолчанию, что передать и что они возвращают, а также, когда они строят запрос, они могут видеть, что требуется и что необязательно. Скажите, что у этого запроса есть свойства, такие как Carriers [Flag Enum] (обязательно), StartDate (обязательно), EndDate (обязательно), PriceRange (необязательно), MinSeatsAvailable (Option) и т.д.... вы понимаете суть.
Когда пользователь получил ответ, он может содержать гораздо больше данных, чем обычный возвращаемый объект. Блок ошибок, отслеживание информации, что угодно, используйте свое воображение.
В примере BusScheduleResponse это может возвращать несколько массивов информации о расписании шины для нескольких несущих.

Надеюсь, это поможет.

Одно слово осторожности. Не смущайтесь и думайте, что я говорю о создании собственных [MessageContract] s. Ваши запросы и ответы - DataContracts. Я просто хочу убедиться, что я не смущаю вас. Никто не должен создавать свои собственные MessageContracts в WCF, если у них нет действительно веских оснований для этого.