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