Utilizzo diretto del canale o utilizzo di un proxy?

Question

Come suggerisce il titolo, sto cercando di capire perché in WCF a volte le persone scelgono di "generare proxy" rispetto all'utilizzo di ChannelFactory per creare manualmente nuove istanze di canale. Ho visto esempi di ciascuno, ma non ho trovato alcuna spiegazione su PERCHÉ si andrebbe per l'uno contro l'altro.

Per essere onesti ho sempre e solo lavorato con canali e il ChannelFactory<T> dal codice che ho ereditato, vale a dire:

IChannelFactory<IDuplexSessionChannel> channelFactory = 
    binding.BuildChannelFactory<IDuplexSessionChannel>(); 

_duplexSessionChannel = channelFactory.CreateChannel(endpointAddress); 

Quindi, perché ho "la generazione del proxy"? Quali sono i vantaggi e gli svantaggi?

Answer 1

La differenza principale è questo:

• generare un proxy richiede solo di conoscere l'URL in cui risiede il servizio. Generando il proxy, tutto il resto (il contratto di servizio ed ai contratti di dati coinvolti) sarà determinato esaminando i metadati del servizio

• al fine di creare direttamente un ChannelFactory<T>, è necessario disporre di un accesso diretto al assembly che contiene quel contratto di servizio T per il quale stai generando una fabbrica di canali. Funziona sempre solo se controlli fondamentalmente entrambe le estremità del canale e puoi condividere l'assembly che contiene quei contratti di servizio. In genere, con un servizio di terze parti, questo non sarà il caso - con i tuoi servizi, sì.

Il secondo punto importante è questo:

• la creazione di un proxy generato fondamentalmente fa le due fasi che si farebbe - creare una ChannelFactory<T>, e da quel, creare il canale reale - in un unico costruttore. Non hai il controllo su questi due passaggi.

• fare la propria creazione di canale è vantaggioso, poiché la creazione di ChannelFactory<T> è il passaggio costoso, in modo da poter memorizzare l'istanza di fabbrica del canale da qualche parte. La creazione e ri-creazione del canale attuale dalla fabbrica è molto meno coinvolto passo che si può fare più spesso

Quindi, se si fa controllare entrambe le estremità della comunicazione, servizio e cliente, si ha la possibilità di condividi i contratti di servizio in un assembly separato, e quindi hai più opzioni.

Con la maggior parte dei servizi di terze parti, semplicemente non hai questa opzione.

Answer 2

L'utilizzo di un proxy è più semplice e comprensibile. Si arriva a trattare in termini di cose semplici - classi e metodi su quelle classi - invece di cose complesse legate alla rete come i canali.

OTOH, questo non è reso più facile dal difetto di progettazione in WCF che impedisce lo stesso uso semplice di un proxy WCF che potremmo fare con i proxy ASMX:

using (var client = new MyServiceClient()) 
{ 
} 

Se si utilizza questo modello con WCF, puoi perdere l'eccezione originale quando il blocco viene chiuso a causa di un'eccezione. client.Dispose() può generare un'eccezione, che sovrascriverà l'eccezione originariamente generata. È richiesto un modello più complesso.

Answer 3

Questo può aiutare:

Quando utilizzare un proxy?

Se si dispone di un servizio che si conosce verrà utilizzato da diverse applicazioni o è abbastanza generico da essere utilizzato in più posizioni, si desidera utilizzare le classi proxy.

Quando utilizzare ChannelFactory?

La classe ChannelFactory viene utilizzata per costruire un canale tra il client e il servizio senza la necessità di un proxy. In alcuni casi, potresti avere un servizio strettamente legato all'applicazione client. In tal caso, è possibile fare riferimento direttamente alla DLL dell'interfaccia e utilizzare ChannelFactory per chiamare i metodi che lo utilizzano.

Si potrebbe anche fare riferimento seguente Link per capire la differenza tra Canale Factory e classe Proxy http://ashishkhandelwal.arkutil.com/wcf/channelfactory-over-proxy-class-in-wcf/

Answer 4

Il vantaggio principale del ChannelFactory è possibile creare il proxy in modo dinamico in fase di esecuzione al volo. Con SvcUtil (Aggiungi riferimento web in VS) si crea il proxy in fase di progettazione, quindi l'implementazione è più statica.