Un saluto a tutti.
In questi giorni mi sto dilettando con Silverlight 2.0 e la sua comunicazione con il server centrale.

Come tutti quelli che trafficano con SL ormai sapranno, la piattaforma espone un accesso ai dati basati unicamente sull'utilizzo di servizi web. Oltre ad un normale WCF, è possibile utilizzare l'intero sistema messo a disposizione da ADO.NET Data Services (codename Astoria) per manipolare le entità in CRUD (Create Read Update Delete).

Nato per l'utilizzo combinato con l'Entity Framework, la piattaforma di servizi è pensata per essere interfacciata anche con dei normali DataContext; unico requisito è che le entità del DataContext in oggetto siano esposte tramite l'interfaccia IQueryable (solo per operazioni di lettura) e IUpdatable se si vuole implementare un CRUD completo.

Chiuso il preambolo iniziale (peraltro inutile e approssimativo) espongo il mio problema...

Ho creato un DataContext custom che implementa l'interfaccia IUpdatable. Implementati tutti i metodi per la manipolazione delle entità nelle varie operazioni di base. Implementato il metodo di salvataggio dei cambiamenti sulle entità coinvolte.

Tutto sembra funzionare correttamente: creo un oggetto sul client Silverlight, lo aggiungo al ServiceDataContext generato dal riferimento al servizio SVC (Astoria) e mando in esecuzione BeginSaveChanges, recuperando poi i risultati nel metodo di callback asincrono con EndSaveChanges.

Le operazioni di inserimento sono perfette: il mio oggetto perfettamente salvato su database viene ritornato al client "farcito" di altre proprietà impostate dal server web centrale (per esempio l'id primario della nuova entità creata).

Avviando una altrettanto semplice operazione di Update (mediante la chiamata ad UpdateObject e relativo SaveChanges) il sistema trasferisce correttamente l'oggetto sul server, esegue le procedure per il salvataggio sul database dopodichè ritorna al metodo di callback del client Silverlight. Sorpresa! Eventuali proprietà dell'oggetto modificate dal server centrale (per esempio un campo stringa utilizzato per portare sul client eventuali errori) non sono rivalorizzate sull'applicativo Silverligh, che ottiene in AsyncState esattamente l'entità che aveva precedentemente inviato al server con UpdateObject.

Se qualcuno sta pensando che non abbia impostato correttamente le proprietà MergeOptions su OverwriteChanges, devo subito confessare che è la prima cosa che ho controllato. La modalità di utilizzo di SaveChanges è impostata su Batch.

Sto cercando di trovare una soluzione che, a quanto pare, non riesco a vedere.
Come in molte altre occasioni (sopratutto ultimamente), mi rimetto al vostro giudizio e aiuto...almeno per non perdere il sonno la notte :)

Grazie a tutti...
Mauro

Grazie per la risposta Marco.
Visto che non ci sono soluzioni mi metto il cuore in pace e cercherò un'altra via...

Il mio problema derivata dal fatto di validare i dati di una entità sul server (quindi centralizzando tutto) piuttosto che sul client. Considero la validazione di un oggetto un processo strettamente legato al layer "business" di un applicativo, quindi non trovo corretto legarlo unicamente all'interfaccia utente (SL è appunto questo, no?).

Per esempio, se voglio permettere di aggiungere degli utenti applicativi dalla mia interfaccia Silverlight, vorrei che questi avessero dei nomi utente validi (per esempio composti solo da caratteri alfanumerici) oppure che gli stessi non fossero duplicati.

Tenterei quindi di inviare, dalla mia applicazione SL, al server, l'utente composto secondo le preferenze dell'operatore. Arrivata sul server la richiesta di nuovo inserimento, lo stesso eseguirebbe le verifiche sopra citate (nel layer business), quindi tornerebbe al client SL una risposta negativa sulla creazione, motivando il rifiuto (username invalido, utente duplicato, ecc...).

Tutto qui...
Spero almeno di aver dato una spiegazione plausibile al mio voler a tutti i costi realizzare l'impossibile :)

Grazie comunque per tutto...
Un saluto.
Mauro