Что лучше в WCF: иметь несколько контрактов операций или только одну операцию с полиморфным контрактом данных?

Мне было интересно, лучше ли в WCF использовать несколько контрактов операций или иметь только один контракт операции с контрактом полиморфных данных.

Приведу небольшой пример:

[OperationContract]
action1Answer action1(action1data a);

[OperationContract]
action2Answer action2(action2data a);

or

[OperationContract]
actionAnswer action(actionContract a);

Контракт действия будет абстрактным классом, от которого унаследуются как action1Contract, так и action2Contract. Контракт действия будет указывать функцию-член do() в своем интерфейсе, которая, в свою очередь, должна быть перегружена в дочерних классах.

Лично мне кажется, что второй подход более интересен, поскольку он позволяет вам красиво инкапсулировать данные и действие в производном actionContract и, в свою очередь, упрощает добавление новых действий. Но я впервые использую WCF, так что, наверное, вам виднее!


c# wcf datacontract operationcontract
person Gab Royer    schedule 09.06.2010    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Этот вопрос граничит с границей Священных войн объектно-ориентированного полиморфизма и SOA, но я дам свои два цента:

Когда вы рассматриваете возможность разработки уровня сервиса, конечному потребителю сервиса должно быть ясно, что передать и чего ожидать; подход 2 не справляется с этим. (Кроме того, при выполнении SOAP с WCF и последующей загрузке из wsdl в других проектах .NET он не помечает должным образом абстрактные классы и не передаются интерфейсы. WSDL не имеют возможности описать базовый класс, не являющийся инстанцируемым, кажется .)

Хотя, я должен признать, я думаю, что второй процесс с использованием KnownTypeAttributes великолепен (как я вижу, только что опубликовал marc_s) - я сам использовал его, учитывая неизвестные будущие требования.

person Matt DeKrey    schedule 09.06.2010
comment
Спасибо за очень информативный ответ! Я никогда не думал, что объектно-ориентированная технология и SOA могут противоречить подобным образом. Несмотря на то, что я предпочитаю второй подход (исходящий из ОО), я мог бы пойти с первым для описания услуги. - person Gab Royer; 09.06.2010
comment
В настоящее время я читаю Microsoft .NET: Architecting Applications for the Enterprise, в котором подробно обсуждается SOA, но в нем немало говорится о шаблонах архитектуры корпоративных приложений Мартина Фаулера; оба должны быть отличным чтением, если вам интересно. - person Matt DeKrey; 09.06.2010

arrow_upward
2
arrow_downward

Я согласен, что подход №2 выглядит лучше - с точки зрения ООП.

Но: SOA / WCF и полиморфизм обычно не очень хорошо сочетаются - SOA (по крайней мере, при выполнении вызовов на основе SOAP) нужны конкретные классы, которые могут быть выражены в WSDL / XSD, определяющем вашу службу.

Вы можете использовать производные типы данных на основе общего базового типа - если вы это сделаете, вам придется изучить атрибут KnownType (или ServiceKnownType), чтобы сообщить WCF, что вы можете возвращать что-то еще, кроме того, что в контракте операции указано на самом деле.

person marc_s    schedule 09.06.2010