Дизайн объектов WCF - ООП против СОА

Question

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

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

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

Answer 1

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

Да.

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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