2009-03-23 16 views
20

Sto scrivendo il mio primo servizio WCF. Ho deciso di scrivere il servizio proprio come una DLL per iniziare e poi di aspetto le cose WCF in seguito, che è dove sono ora.WCF: MessageContract, DataContract ... Confused?

Sono stato avvisato dall'architetto che dovrei attenermi a un formato specifico per gli oggetti messaggio che ho fatto. Comunque ho usato interfacce, tipi complessi e liste di questi nei miei oggetti messaggio. Sto arrivando ad aggiungere gli attributi e sto diventando un po 'confuso.

Ecco un esempio di spettacolo del mio codice.

[ServiceContract] 
public interface MyServiceContract 
{ 
    [OperationContract] 
    MyMethodResponseMessage MyMethod(MyMethodRequestMessage request); 
} 

public class MyService : MyServiceContract 
{ 
    public MyMethodResponseMessage MyMethod(MyMethodRequestMessage request) 
    { 
     //Do things 
    } 
} 

//Messages 
[MessageContract] 
public class MyMethodResponseMessage 
{ 
    [MessageBodyMember] 
    public MyMethodResponse Body { get; set; } 
} 

[DataContract] 
public class MyMethodResponse 
{ 
    [DataMember] 
    public IMyComplexTypeItem { get; set; } 

    [DataMember] 
    public List<IMyComplexType> Items { get; set; } 

    [DataMember] 
    public bool Success { get; set; } 
} 

//DTO  
public interface IMyComplexType 
{ 
    [DataMember] 
    string Identity { get; set; } 
} 

[DataContract] 
public class MyComplexType1 : IMyComplexType 
{ 
    [DataMember] 
    public virtual string Identity 
} 

Chiunque può commentare sulla correttezza nell'uso di MessageContract, DataContract, DataMember e Serializable ecc? Eventuali puntatori o errori evidenti?

Anche quale serializzatore è il migliore da usare? e qual è la strategia migliore per assicurarmi di ottenere un XML ben formato da questo in modo che altri clienti possano consumare facilmente il mio servizio?

risposta

15

Per la richiesta/risposta - un [DataContract] funzionerebbe altrettanto bene. Uno dei vantaggi dei contratti con i messaggi è che è possibile impostare la privacy rispetto ai membri, ma in molti casi ciò non è necessario. In questi casi, preferisco mantenere il contratto il più semplice possibile, proprio come un contratto di dati.

Re cui serializzatore - che è in gran parte un fattore della configurazione. Per impostazione predefinita su http, ad esempio, sarà DataContractSerializer.

Non sono sicuro, tuttavia, che l'elenco di IMyComplexType funzioni molto bene. Potresti provare, ma generalmente vuole tipi concreti. Si noti che con le classi base è possibile utilizzare [KnownType] per specificare i sottotipi consentiti.

Si noti che diversamente XmlSerializer, non è un requisito per i membri di raccolta per avere setter - anche se potrebbe essere necessario aggiungere un metodo OnDeserializing callback per inizializzare la lista se lo fai (WCF non chiama costruttori).

A parte: è anche possibile utilizzare protobuf-net con contratti dati e WCF (purché abbiano un Ordine esplicito); questo è più densamente imballato rispetto al normale xml. Al momento, tuttavia, non ha alcun supporto per i contratti con i messaggi.

+0

Grazie Marc, hai ragione sulla classe di base. Funziona un po 'meglio. Darei un'occhiata al metodo OnDeserializing, esultare per l'idea. Sono vincolato a Xml per questo dalla progettazione. –

2

Anche se non è una risposta diretta alla tua domanda, vale la pena di prendere nota di quanto segue dal MSDN -Using Message Contracts

Ogni messaggio intestazione e il corpo del messaggio parte individuale viene serializzato (trasformato in XML) utilizzando la serializzazione prescelto motore per il contratto di servizio in cui viene utilizzato il messaggio. Il motore di default serializzazione, la XmlFormatter, in grado di gestire qualsiasi tipo che ha un contratto di dati , sia esplicitamente (avendo il sistema. Runtime. Serializzazione. DataContractAttribute) o implicitamente (per essere un tipo primitivo, avendo il System.SerializableAttribute e così via).

enter image description here

Problemi correlati