Наследование WCF MessageContract

В конце концов я нашел это сообщение в блоге, которое попало в самую точку -

К сожалению, способ сужения выражены в WCF делает очень легко забыть, какова их цель: для определения сообщений, отправляемых операция и отправка обратно из операция. На самом деле вам нужно подумайте «как бы я выразил эти данные в XML? ». XML не поддерживает наследование, так что все, что вы положили в в контракте должны быть некоторые способ отображения в XML. Данные контракты, используемые для определения сообщений просто удобство типа .NET для генерации XML для данных вы хотите пройти - если вы их просматриваете иначе вам суждено мир боли. Так что подумайте о данных ты хочешь пройти, а не как может быть представленным в вашем бизнес-уровень и создайте свой DataContracts accordingly.

http://www.dotnetconsult.co.uk/weblog2/PermaLink,guid,a3775eb1-b441-43ad-b9f1-e4aaba404235.aspx

So I will be refactoring to provide an additional method with an explicit contract type. This will also allow me to clean up the service implementation by removing all the type checking.

Thanks for the assistance.

OK, first question is: why are you really using Message contracts? Do you really have a need for that??

Typically, message contracts are only ever used when you need to tightly control the layout of your SOAP message, e.g. to satisfy a legacy system you need to call which requires specific headers and such.

A "normal" WCF call should hardly ever need to use a message contract.

You define your service calls (the methods on your service) using [ServiceContract], and the data structures being passed around as [DataContract]. If you have a DataContract, you have more options as to how to deal with inheritance / polymorphism in your service (more than with the message contract construct).

Marc

Можно ли изменить BaseMessage так, чтобы это был конкретный класс с конструктором без параметров?

Сообщение об ошибке сообщает, что нет способа инициализировать объект типа BaseMessage, потому что он абстрактный.

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

Попробуйте украсить свой [ServiceContract] атрибутом KnownType . Поскольку TestMessage не «видно» из общедоступной операции, это помогает водопроводчику знать, как обращаться с ним, когда оно его видит.

Если это должно позволить [DataContract] быть сериализованным как TestMessage , вероятно, вам все равно придется обрабатывать несколько сообщений по-разному с помощью ' is » или какой-то другой кастинг.