Windows Communication Foundation: differenze tra le versioni

Versione delle 11:40, 13 nov 2007

Versione delle 11:41, 13 nov 2007

Riga 25:

Dopo tanta teoria, è arrivato il momento di passare al codice. Come esempio verrà creato un servizio che riceve in input un codice prodotto e restituisce tutte le informazioni legate al prodotto con quel codice.

La prima cosa da fare quando si costruisce un servizio con WCF è stabilire il contratto di comunicazione tramite interfaccia che nel nostro caso è la seguente:

[ServiceContract]

public interface IContract {

Riga 35 ⟶ 34:

Una volta stabilito quali servizi mettere a disposizione, si determina quali dati l'entità Product debba pubblicare e quali invece debba mantenere privati:

[DataContract]

public class Product{

Riga 62 ⟶ 60:

Nonostante questo buon livello di controllo a volte si ha bisogno di un controllo totale sul processo di serializzazione, in questo caso la cosa migliore è marcare l'interfaccia con l'attributo XmlSerializerFormat che invece di sfruttare il serializzatore di default utilizza il serializer standard del .NET Framework che viene utilizzato anche per i WebService Asmx.

A questo punto l'interfaccia è pronta, le classi sono stabilite, manca solo l'implementazione del codice per restituire i dati:

public class ProductRetriever : IContract {

public Product GetProductById(string IdProduct){

Riga 78 ⟶ 75:

Come già accennato, la magia di WCF sta in parte nel codice semplificato ed unificato per ogni modalità di comunicazione, e in parte nel fatto che semplicemente cambiando la configurazione si può passare da http a TCP, da messaggi in chiaro a messaggi criptati, ecc ecc. In realtà tutto quello che si può configurare da file può essere realizzato anche da codice, ma non è buona pratica cablare nell'applicazione queste informazioni. Può essere invece molto utile realizzare una form di gestione della configurazione al fine di rendere la modifica più semplice in fase di deploy.

Il posto naturale dove inserire le informazioni di configurazione è il file .config all'interno del quale va inserito un nodo system.serviceModel che è il contenitore di ogni impostazione:

<configuration>

<system.serviceModel>

Riga 93 ⟶ 89:

Dal file di configurazione possiamo ricavare tutte le informazioni necessarie per il funzionamento del servizio e utilizzarle da codice per istanziare il servizio utilizzando l'oggetto ServiceHost in una semplice console application:

using (ServiceHost serviceHost = new ServiceHost(typeof(WinFXItalia.Library.ProductRetriever), "http://localhost/ws/svc")) {

serviceHost.Open();

Riga 111 ⟶ 106:

Attualmente, Visual Studio non ha un'interfaccia grafica per costruire in automatico il proxy, quindi la sola possibilità è utilizzare il tool SvcUtil.exe da riga di comando. Questo tool risulta molto comodo perché non solo crea automaticamente il proxy, ma anche il file di configurazione che il client può utilizzare per la connessione. Quest'ultima frase lascia capire che anche il client può essere pilotato da configurazione senza bisogno di codice esattamente come si fa con il servizio.

Avendo anche il client un EndPoint, le informazioni da pubblicare sono le stesse del servizio: l'Address, il Binding ed il Contract. I primi due corrispondono ai dati dell'endpoint utilizzato dal servizio, mentre il contract corrisponde alla classe automaticamente generata nel proxy. L'altra differenza rispetto alla configurazione del servizio è il nome del nodo principale che contiene i dati: invece di avere un nodo <services> con diversi <service> innestati, esiste un nodo client con tutti gli endpoint figli:

<configuration>

<system.serviceModel>

Riga 124 ⟶ 118:

Anche qui, una volta stabilita l'interfaccia si passa al codice per invocare il servizio e ricevere i dati. Nel nostro caso il client sarà una classica Windows Application che al click di un bottone invoca il servizio.

using (ContractProxy proxy = new ContractProxy()) {

WinFXItalia.Library.Product p = proxy.GetProductById("1");