WCF MessageContract Inheritance

Question

Jestem całkiem nowy w WCF i mam tylko pytanie, jak poprawnie uzyskać dziedziczenie MessageContract. Uproszczona wersja mojej konfiguracji wygląda następująco: "podstawowy" typ komunikatu, a następnie kolejna wiadomość "testowa", która po niej dziedziczy.

[MessageContract] 
public abstract class BaseMessage 
{ } 

[MessageContract] 
public class TestMessage : BaseMessage 
{ } 

Mam następnie asynchronicznego OperationContract na ServiceContract zdefiniowany jako:

[OperationContract(AsyncPattern = true)] 
IAsyncResult BeginFindRequest(BaseMessage request, AsyncCallback callback, object asyncState); 

problem, że jestem coraz to podczas wywoływania metody BeginFindRequest i przechodzącą w instancji TestMessage parametru żądanie, struktura WCF odformalizuje instancję TestMessage do BaseMessage po stronie usługi/serwera. Jak to jest zdefiniowane jako abstrakcyjne klasy, to wyniki w następujący błąd:

"The message cannot be deserialized into MessageContract type BaseMessage since it does not have a default (parameterless) constructor."

Z ograniczonych informacji, które mogę znaleźć na MessageContract dziedziczenia, wydaje się, że powinien po prostu pracować.

Moje pytanie brzmi: czego mi brakuje, aby to zadziałało; czy powinienem raczej zdefiniować oddzielne OperationContract na ServiceContract specjalnie dla tego typu - wadą jest to, że mogłem skończyć z wieloma dodatkowymi OperationContracts?

Answer 1

Czy można zmienić BaseMessage tak, aby był konkretną klasą z konstruktorem bez parametrów?

Komunikat o błędzie informuje, że nie ma możliwości zainicjowania obiektu typu BaseMessage, ponieważ jest on abstrakcyjny.

Answer 2

OK, pierwsze pytanie brzmi: dlaczego tak naprawdę używasz umów z wiadomościami? Czy naprawdę tego potrzebujesz?

Zwykle umowy z wiadomościami są używane tylko wtedy, gdy trzeba ściśle kontrolować układ wiadomości SOAP, np. aby zaspokoić istniejący system, który musisz wywołać, który wymaga określonych nagłówków i podobnych.

"Normalne" wywołanie WCF praktycznie nie powinno wymagać zawarcia umowy z wiadomością.

Zdefiniujesz swoje zgłoszenia serwisowe (metody w Twojej usłudze), używając [ServiceContract], a struktury danych są przekazywane jako [DataContract]. Jeśli masz DataContract, masz więcej opcji, jak radzić sobie z dziedziczeniem/polimorfizmem w twojej usłudze (więcej niż przy konstruowaniu kontraktu z wiadomościami).

Marc

Answer 3

Błąd po prostu chce mieć domyślny pusty contructor że można go używać. Jednakże zgadzam się z marc_s; w projektach, nad którymi pracowałem rzadko korzystałem z kontraktu na wiadomości, jedyny przypadek, jaki pamiętam, był częścią usługi transferu plików, w której fragmenty plików były przekazywane w mesasges.

Answer 4

Spróbuj zdobienia swojego [ServiceContract] za pomocą atrybutu KnownType. Ponieważ TestMessage nie jest "widoczny" z operacji publicznej, pomaga to hydraulikom wiedzieć, jak traktować go, gdy go zobaczy.

Jeśli ta powinna umożliwić [DataContract] być szeregowane jako TestMessage swój nadal prawdopodobnie trzeba obsłużyć wiele różnie wiadomości poprzez „is a” lub jakiś inny odlewu.

Answer 5

W końcu znalazłem ten wpis na blogu, który uderzył w sedno -

Unfortunately the way that contracts are expressed in WCF makes is very easy to forget what their purpose is: to define the messages send to the operation and being sent back from the operation. In reality you have to think “how would I express this data in XML?”. XML doesn’t support inheritance so whatever you put in the contract is going to have to have some way of mapping to XML. The data contracts used to define the messages are simply a .NET typed convenience for generating the XML for the data you want to pass – if you view them any other way you are destined for a world of pain. So think about the data you want to pass, not how it may happen to be represented in your business layer and design your DataContracts accordingly.

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

Więc będę refaktoryzacji w celu zapewnienia dodatkowej metody z wyraźną typu umów. Pozwoli mi to również wyczyścić implementację usługi, usuwając wszystkie sprawdzenia typów.

Dzięki za pomoc.