Дизайн объекта WCF - OOP и SOA

Question

Каков правильный способ обработки полиморфных бизнес-объектов в мире WCF/SOAP?

Мне кажется, что SOA и ООП находятся в противоречии друг с другом - для того, чтобы разоблачить чистый WSDL, вам нужны конкретные объекты, как правило, даже не используя наследование. С другой стороны, предположительно в базовой системе, вы захотите следовать правильному дизайну OO.

Что люди обычно здесь делают? Построить набор объектов контракта WCF, отказаться от принципов ООП, а затем преобразовать их в другой набор объектов в реальных логических слоях и обратно?

Answer 1

Что люди обычно здесь делают? Построить набор объектов контракта WCF, отказаться от принципов ООП, а затем преобразовать их в другой набор объектов в реальных логических слоях и обратно?

Да.

Способ передачи данных WCF в конечном итоге создает множество ограничений на то, что вы можете и чего не можете сделать с объектами контракта. То, что вы не можете сделать, оказывается «самым полезным».

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

Answer 2

После прочтения библиотеки Томас Эрл, я пришел к следующему выводу:

Думай о WCF контрактов/SOAP Message просто как сообщение о том, что услуги используют для общения (не туго перевязать, что к объектам в ваш код).

Затем вы можете использовать ООП для разработки кода, который изящно обрабатывает эти сообщения, используя общие методы ООП.

Answer 3

Вы используете абстракцию (тип интерфейса), аннотированную атрибутами WCF, чтобы определить ваш контракт на обслуживание.

Это зависит от абстракции, которая соответствует ООП, а также определения конечной точки обслуживания, которая является SOA.

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

Answer 4

Все замечательные комментарии по этой теме! Я добавлю свой голос к понятию адаптера для медиации между ориентацией обслуживания и ориентацией объекта. Мне также нравится подход Томаса Эрла, где в его сервисной модели он вводит понятие «прикладные услуги» и «бизнес-услуги». Это путь для ваших точек интеграции с вашей конкретной прикладной/бизнес-средой (т. Е. Вашей объектно-ориентированной и компонентной платформы/API). Этот способ должен привести к значительно лучшей компоновке и, следовательно, к возможностям для ваших корпоративных гуру.