Образец запроса / ответа при реализации SOA

17

В каком-то корпоративном проекте (.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?

    
задан UserControl 16.06.2010 в 09:17
источник

1 ответ

28

Образец, о котором вы говорите, основан на разработке контракта First. Тем не менее, не обязательно использовать шаблон блока ошибок в WCF, вы все равно можете сбросить ошибки на клиенте вместо использования блока Error Xml. Блок Error использовался очень долго, и поэтому многие люди привыкли к его использованию. Кроме того, другие разработчики платформы (например, java) не так знакомы с faultExceptions, хотя это отраслевой стандарт.
Ссылка

Шаблон 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, если у них нет действительно веских оснований для этого.     

ответ дан CkH 16.06.2010 в 22:18
  • Просто чтобы добавить к преимуществам, и это мой любимый. * DataContracts являются устойчивыми к изменениям (проще для версии), чем OperationContracts. Если вы добавите параметр, который вы меняете OperationContract, это является нарушением изменений для старых потребителей. Если вы добавите свойство в свой DataContract, старые версии могут работать (если правильно закодировано). –  Miguel Madero 26.06.2012 в 00:21
  • Что касается вашей второй пули, как бы вы пометили свойство по контракту данных по мере необходимости, необязательно и т. д.? –  elucid8 09.08.2013 в 18:31
  • elucid8, в DataMember вы можете добавить IsRequired = true / false, чтобы сделать свойство обязательным / необязательным. –  CkH 16.12.2013 в 20:25