I wrapper dei parametri di richiesta / risposta sono buoni?

Question

I wrapper dei parametri di richiesta / risposta sono buoni?

#1 da (9 voti)

4

Ho visto diversi modi per progettare i servizi WCF, e sembra che alcuni sviluppatori preferiscano i wrapper dei parametri, mentre altri preferiscono i parametri "naked". Per spiegare cosa intendo, considera le seguenti interfacce di servizio:

Parametri "nudi"

[ServiceContract]
public interface IService
{
    [OperationContract]
    string[] GetValuesByType(string groupName, ValueTypeEnum valueType)
}

Wrapper di parametri

[DataContract]
public class GetValuesByTypeRequest
{
    [DataMember]
    public string GroupName { get; set; } 

    [DataMember]
    public ValueTypeEnum ValueType { get; set; }
}

[DataContract]
public class GetValuesByTypeResponse
{
    [DataMember]
    public string[] Result { get; set; } 
}

[ServiceContract]
public interface IService
{
    [OperationContract]
    GetValuesByTypeResponse GetValuesByType(GetValuesByTypeRequest request)
}

Suppongo che ci siano casi in cui i wrapper di parametri rendono più semplice mantenere il servizio su diverse versioni del software, dal momento che è possibile controllare la serializzazione di ciascun membro un po 'più direttamente di quanto si possa fare con il primo metodo. Ma, ad essere onesti, i wrapper dei parametri sembrano molto più codice per un beneficio minimo. Ho sbagliato qui?

c# design-patterns wcf

posta p.s.w.g 28.02.2013 - 17:02

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns wcf

Differenza tra Zend Framework e Zend Server? Come gestire un singolo prodotto software per più clienti?

score 9 · Accepted Answer

Hai ragione, in quanto in termini di come il codice cambierà nel tempo, in genere mi spingo verso i wrapper di parametri in modo che più tardi, quando ho bisogno di più informazioni per eseguire la stessa funzione quando aggiungo una nuova funzione, posso conserva le firme e aggiungi un'altra proprietà all'oggetto wrapper esistente.

Quando si tratta di creare contratti di comunicazione come si fa quando si lavora con WCF, ciò preserverà il contratto e consentirà ai clienti che lavorano con il vecchio oggetto di continuare a funzionare come in passato, semplicemente non otterranno il vantaggio le nuove offerte di proprietà. La serializzazione semplicemente ignorerà la proprietà e passerà felicemente l'oggetto. Quando i client vengono aggiornati per "conoscere" la nuova proprietà, possono migrare il loro codice di conseguenza.

Se dovessi cambiare la firma di quel metodo aggiungendo un parametro, interromperesti il contratto che hai con tutti i tuoi clienti, costringendoli tutti a rilasciare in modo sincrono gli aggiornamenti con la tua modifica della firma.

Se il tuo codice ha client per i quali non controlli il ciclo di distribuzione, fai in futuro a te (o ai futuri sviluppatori sul tuo codice) un favore e una progettazione con i wrapper di parametri. Se controlli tutto il codice client e le distribuzioni e puoi forzarli tutti in una volta, allora probabilmente non importa. Ma nel grande schema delle cose, non è una tonnellata di codice extra ed è una buona abitudine (IMHO).