Передовая практика объектов данных WCF

Question

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

Моя служба соответствует шаблону, приведенному ниже;На самом деле у меня есть намного больше методов, чем это, поэтому дублирование кода является проблемой.

<ServiceContract()>
Public Interface IPublicApis

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataA(ByVal req As RequestA) As ResponseA

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataB(ByVal req As RequestB) As ResponseB

    <OperationContract(AsyncPattern:=False)>
    Function RetrieveQueryDataC(ByVal req As RequestC) As ResponseC

End Interface

Следуя этому совету, я сначала создал схемы для объектов Request и Response.Затем я использовал SvcUtil для создания результирующих классов, так что я уверен, что объекты могут использоваться другими языками, и клиенты найдут схемы, с которыми легко работать (без ссылок на другие схемы).Однако, поскольку запросы и ответы имеют схожие данные, я хотел бы использовать интерфейсы и наследование, чтобы не реализовывать несколько версий одного и того же кода.

Я думал о написании своей собственной версии классов с использованиеминтерфейсы и наследование в отдельной библиотеке классов, и реализация всей логики, безопасности, логики поиска данных там.Внутри каждой операции я просто конвертирую RequestA в свой InternalRequestA и вызываю функцию процесса InternalRequestA, которая возвращает InternalResponseA.Затем я преобразую это обратно в ResponseA и отправлю клиенту.

Эта идея сумасшедшая?!?У меня возникают проблемы с поиском другого решения, которое использует внутреннее преимущество наследования, но при этом предоставляет клиенту чистые схемы, поддерживающие будущие обновления.

Answer 1

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

У нас не было реальных проблем с использованием наследования с объектами контракта данных.

Итак, учитывая, что выЯ четко контролирую схемы (т.е. они не указываются внешне) и может эффективно использовать встроенные в WCF возможности контракта на данные. Я изо всех сил пытаюсь понять, какую выгоду вы получите от дополнительных сложностей и усилий, подразумеваемых в предложенном вами подходе.

На мой взгляд, логика, связанная с обработкой сообщений, должна быть полностью отделена от самих сообщений.