Стоит ли избегать наследования сообщений в WCF?

Question

Обычно я стараюсь избегать использования наследования в контрактах WCF, предпочитая композицию.

Но в следующей ситуации ...

• У меня есть сервисная операция, которая может привести к одной из двух вещей: ResultA и ResultB.
• В ответном сообщении содержится логическое значение / перечисление, сообщающее об этом результате.
• В ответном сообщении есть ряд других свойств. Некоторые из них актуальны только в случае ResultA, а некоторые - только в случае ResultB.

Я вижу свои варианты:

1. Имейте один контракт с ответным сообщением, который содержит все, и когда свойства не релевантны, они остаются равными нулю Затем клиент должен посмотреть на bool / enum, чтобы увидеть его ResultA или ResultB и соответственно игнорировать свойства.
2. Имеет 2 контракта с ответными сообщениями, оба наследуются от общей базы. Один представляет ResultA и его соответствующие свойства, а другой представляет ResultB и его соответствующие свойства.

Я предпочитаю вариант 2 по ряду причин, но он нарушает композицию по правилу наследования.

Что думают люди?

Answer 1

Мое внутреннее чувство здесь - «перепроектируй свой интерфейс». Наличие методов с сомнительными типами возврата обычно не является признаком хорошего дизайна. Это приводит к большому количеству ненужной и подверженной ошибкам логики в каждом вызывающем методе.

Поэтому я бы предложил «секретный вариант № 3»: переделать интерфейс в два отдельных метода.

Answer 2

Предпочитайте композицию наследованию! = Никогда не используйте наследование: -)

Answer 3

Все правила должны быть нарушены. Если вы повторно используете объекты и системы позволяют вам использовать наследование ... почему бы не использовать его? Как говорит Фил Хаак ... подумайте сами.

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

Предпочитаю композицию наследованию (Стив Роу) Вот другой угол. Но если вы читаете его, он говорит о повторном использовании функции, а не данных.