178 messaggi dal 12 luglio 2007
Ciao,
ho realizzato un webservice WCF che sto consumando da un client WPF e mi chiedevo:
perche' WCF espone un modello di classe simile al mio ma non il mio?
io uso la mia classe MieiModelli.Societa ma il webservice espone la sua versione della classe MioService.Societa. Questo mi sega le gambe perche' fa un casino con le interfacce implementate.
ho creato una IEtichetta che espone due property Get/Set e due ReadOnly Property. Anche linkando nel client il progetto con i modelli se faccio una trycast verso IEtichetta ricevo una nothing come risposta. la cosa ancora piu' divertente e' che la classe MioService.Societa non espone le due ReadOnly Property mentre le altre due in Get/Set si.
C'e' un modo per trasferire anche le interfacce o deve essere il webserice ad avere due metodi, uno che espone tutto l'oggetto e l'altro che espone solo l'interfaccia?
103 messaggi dal 04 ottobre 2010
I webservices sono concettualmente pensati per essere consumati da applicazioni Client, in maniera indipendente dal codice di programmazione implementato nel client stesso. Per ottenere una simile versatilità, si è scelto di comunicare le informazioni dei tipi restituiti da questi metodi, tramite un canale comunicativo che usufruisce di un protocollo apposito. Nel caso di un web service classico, nell'ambiente .Net Framework, si utilizza il protocollo SOAP (Simple Object Transfer Protocol), che descrive le classi coinvolte dal webservice tramite xml. Se da Visual Studio espandendo il webservice provi a consultare il file autogenerato .wsdl associato ad esso, potrai ritrovarti infatti questa classe condivisa.
Tuttavia, i tipi riconosciuti dal SOAP sono appositamente limitati per aumentare la compatibilità tra linguaggi (per esempio una List non trova spazio in questo protocollo).
Un metodo WebService che si dichiara di tipo List, sarà riconosciuto infatti come errore.
Per poter personalizzare questo comportamento, puoi ad esempio crearti un oggetto MyList che espanda List e che implementi l'interfaccia IXmlSerializable, definendone quindi gli appositi metodi all'interno della classe. Potresti quindi rendere la tua classe serializzabile (la serializzazione deve "scomporre" proprietà e campi della classe in tipi serializzabili dall'xml), nel caso non lo fosse già nativamente tramite questa interfaccia quindi. Tornando a noi, per i motivi sopra spiegati, un oggetto ottenuto dal webservice è quindi non sempre riconducibile alla classe corrispettiva del client in maniera automatica. Gli unici che possono essere riconducibili sono i tipi primitivi stessi. E' per questo che il webservice definisce delle classi a parte simili a quelle della tua logica di business. Se tuttavia, sia il Client che attinge al webservice che l'applicativo che lo fornisce, puntano alla stessa sorgente dati, quando possibile è preferibile che il webservice risponda con un id (o un array di id) e ricrearsi questo o questi oggetti leggendo, per esempio, dal database (o da una sorgente dati generica). Stessa cosa per i parametri da passare ai metodi del web service. Altrimenti, se non è possibile percorrere questa strada, potrebbe essere necessario passare alla conversione dalla classe webservice alla classe client che attinge ad essa (o viceversa nel passaggio di parametri da dare al metodo webservice) in maniera manuale.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.