Дизайн объектов WCF - ООП против СОА
Как правильно обрабатывать полиморфные бизнес-объекты в мире WCF/SOAP?
Мне кажется, что SOA и OOP находятся в противоречии друг с другом - чтобы выставить чистый WSDL, вам нужны конкретные объекты, обычно даже без использования наследования. С другой стороны, предположительно в базовой системе вы захотите следовать правильному дизайну ОО.
Что люди обычно делают здесь? Построить набор объектов контракта WCF, отказываясь от принципов ООП, затем преобразовать в и из другого набора объектов в реальных логических слоях?
4 ответа
Что люди обычно делают здесь? Построить набор объектов контракта WCF, отказываясь от принципов ООП, затем преобразовать в и из другого набора объектов в реальных логических слоях?
Да.
То, как WCF сериализует вещи, в конечном итоге накладывает множество ограничений на то, что вы можете и не можете делать с объектами контракта. То, что вы не можете сделать, в конечном итоге оказывается "почти чем-нибудь полезным".
Я обнаружил, что все становится намного понятнее, если вы рассматриваете объекты WCF-контракта просто как механизм передачи данных. В основном, как строго / статически типизированный XML.
Вместо преобразования вашего бизнес-объекта в строку XML (и обратно), вы конвертируете свой бизнес-объект в объект контракта WCF (и обратно), но в остальном он похож
Прочитав библиотеку Томаса Эрла, я пришел к следующему выводу:
Думайте о сообщениях WCF Contracts/SOAP как о просто сообщении, которое сервисы используют для связи (не привязывайте это жестко к объектам в вашем коде).
Затем вы можете использовать ООП для разработки базы кода, которая изящно обрабатывает эти сообщения, используя обычные методы ООП.
Все отличные комментарии на эту тему! Я добавлю свой голос к понятию адаптера для посредничества между вашей сервисной ориентацией и объектной ориентацией. Мне также нравится подход Томаса Эрла, когда в своей модели услуг он вводит понятия "сервисы приложений" и "бизнес-сервисы". Это путь для ваших точек интеграции с вашим конкретным приложением / бизнес-средой (то есть вашей объектно-ориентированной и компонентно-ориентированной средой /API). Этот способ должен обеспечить гораздо лучшую компоновку и, следовательно, возможности для ваших гуру корпоративной среды.
Вы используете абстракцию (тип интерфейса), аннотированную атрибутами WCF, чтобы определить свой контракт на обслуживание.
Это зависит как от абстракции в соответствии с ООП, так и от определения конечной точки службы, которая является SOA.
В общем, если вы обнаружите, что получаете бизнес-объекты с зависимостями, вам следует рассмотреть возможность перетаскивания таких зависимостей на бизнес-уровень службы, а не внедрять зависимости в бизнес-объекты. Бизнес-уровень службы будет выступать в качестве посредника, действующего как для прокси-сервера службы WCF, так и для бизнес-объектов. В отличие от того, чтобы бизнес-объекты действовали на прокси службы WCF.