Шаблоны для компенсации отсутствия наследования в SOA

Question

Я считаю наследование и концепцию базового класса наиболее сильной стороной ООП.Но это не поощряется в SOA.Итак, каковы популярные схемы преодоления этого ограничения в SOA?Не могли бы вы предоставить учебные пособия, которые объясняют (с демонстрацией кода в WCF) эти шаблоны?

Примечание. Это НЕ общий вопрос о шаблонах, доступных в SOA.Но это более конкретно для вышеупомянутой проблемы.

Примечание: я использую WCF для SOA.

---

Чтение:

1. «Не используйте абстрактный базовый класс в дизайне;но в моделировании / анализе »

2. Как на самом деле предполагается реализовать архитектуру SOA?

3. Как бороться с полиморфизмом Java в сервис-ориентированной архитектуре

4. Как быстро освоить SOA?

5. Что такое сервис-ориентированная архитектура?

6. Действительно ли DDD и SOA хорошо играют вместе?

7. Вопросы разработки SOA и WCF: это необычный дизайн системы?

8. Разработка контрактов данных WCF и операций

9. Развернуть объекты в C # 4.0

Answer 1

Я считаю наследование и концепцию базового класса наиболее сильной стороной ООП.

Не переоценивайте силу наследования - почти все шаблоны GoF предназначены для предотвращения неправильного использования наследования.

Но это не поощряется в SOA.

Нет, это вообще не поощряется.Зачем?Потому что в SOA у вас есть сервис, обеспечивающий некоторые операции.Сам сервис определяется описанием сервиса (контракт / интерфейс).В случае SOAP сервисный контракт описан в WSDL.Если вам нужен другой сервис, обеспечивающий такой же набор операций с немного другим поведением, вы просто снова внедрите интерфейс и настроите клиент на новый сервис (предоставив новый URL-адрес конечной точки).Таким образом, наследование с контрактом на обслуживание «работает», но оно не работает так же, как с контрактами на данные.

Каждая операция сервиса обычно принимает некоторые данные и возвращает некоторые данные.Эти данные снова описаны в описании услуги.В случае сервисов SOAP данные описываются как XSD.Когда вы отправляете данные от клиента к сервису (или в обратном направлении), данные должны быть сериализованы, и пункт назначения должен иметь возможность десериализации их (если вы не хотите работать с конвертами SOAP напрямую или если вы не хотите использовать xsd: any = нетипизированный XML как переданныйданные).Если вы хотите использовать наследование в контракте данных, вы должны каким-то образом включить информацию о производных контрактах в описание сервиса.Только после включения этой информации в описание сервиса вы можете информировать потребителей сервиса о существовании унаследованных контрактов данных (им нужна эта информация для работы с производными типами).

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

В случае не совместимых и тесно связанных систем (не SOA) вы также можете использовать NetDataContractSerializer, которыепозволяет использовать наследование без каких-либо ограничений, поскольку каждое сериализованное сообщение содержит информацию о типе CLR, необходимую для десериализации, и клиенты со службой должны совместно использовать сборки контракта данных.

Answer 2

Независимо от того, думаете ли вы о SOA, реализованном с помощью SOAP, REST или обмена сообщениями, службы ориентированы на документы. Сервисы не являются объектно-ориентированными .

Хотя полиморфизм является мощным инструментом проектирования в OOD, он не применим в SOA, поскольку моделирование SOA не включает классы.

Answer 3

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

Наличие наследования будет просто означать, что отношения между вашими объектами сложно моделировать и / или изменить со временем. В основном это означает использование объектов модели POCO.

Если вы хотите добавить бизнес-логику к себе, используйте миксины для имитации наследования.