Sfruttare le Action ASP.NET MVC da Silverlight

Sto scrivendo questo post da San Leonardo in Passiria (in Südtirol...uno dei posti piú belli al mondo, a mio parere), usando il mio smartphone; ogni giorno mi sorprendo sempre di più come l'informatica fa passi da gigante, come nascono nuove tecnologie o nuove tecniche per sfruttare meglio quelle esistenti. E in questo post, nel mio piccolo, voglio condividere la mia recente esperienza in questo senso.

Poche settimane fa stavamo lavorando ad una nuova versione di un applicativo rilasciato inizialmente nel 2008, basato su Microsoft Silverlight e su WCF Ria Services; naturalmente la primissima versione era basata su SL2 e .NET DataServices, poi ripetutamente aggiornato a SL3/4 e WCF Ria Services. Le revisioni successive non hanno minimamente modificato l'approccio architetturale iniziale, pur introducendo quanto di meglio era disponibile per semplificare la vita dello sviluppatore.

Ma con il crescere dei dati gestititi, nel corso degli anni, il sistema ha sempre piú dato segni di soffrire sul lato performance. Benché il tutto fosse stato fatto nella maniera piú corretta, il colloquio tra lo "smart client" Silverlight e la piattaforma di servizi lato server, sembrava essere il vero collo di bottiglia.

In tutta onestà c'é da dire che Silverlight, ed in particolare i Ria Services funzionano molto bene se la "line of business" comprende l'accoppiamento lato server con Entity Framework: tutto é perfettamente integrato e funzionale.

In questa particolare situazione si era scelto di gestire il layer di accesso ai dati usando un altro OR/M, quindi non si sono rispettati i dettami Microsoft, per una serie di motivi che non vi sto a raccontare.

Detto questo, per appurare che il reale problema di lentezza fosse nel processing dei Ria Services, si é fatto un piccolo esperimento: lato server si é creato un metodo IQueryable che emetteva una lista di oggetti "Poco" hard-coded; quindi si é misurato il tempo in cui gli stessi raggiungevano il punto di debug posto sullo smartclient Silverlight. I risultati non sono stati incoraggianti; tanto piú che sembravano deteriorare man mano che i Ria Services mantenevano il tracking di una quantitá di dati sempre maggiore.

E qui finalmente torniamo al tema del post: perché devo essere "obbligato" ad usare una tecnologia (i Ria Services) se non la sfrutto appieno e, sopratutto, peggiora le performance generali del mio sistema?

Con "non sfruttare appieno" le possibilitá della tecnologia, mi riferisco proprio al tracking dello stato delle entitá inviate dal server al client; la capacità dei Ria Services di determinare, in ogni momento, se un particolare oggetto é stato creato modificato o eliminato da operazioni client non ancora "commitate" sul server.

Personalmente ho sempre pensato che strumenti automatici o semi-automatici abbiano sempre avuto una valenza enorme nel lavoro di uno sviluppatore; specialmente se si voleva essere un "utilizzatore" di una tecnologia piuttosto che un esperto. Recentemente ho cambiato totalmente idea; ritengo assolutamente giusta l'asserzione "Never protect the developer", lasciando quindi l'onere di capire veramente una tecnica, prima di utilizzarla. 

Perché devo affidarmi ad un sistema automatico che fa un sacco di cose in background quando io ho solo bisogno di un "attrezzo" che trasporti dal server al client (e viceversa) un set di oggetti?

Togliendo dall'equazione i Ria Services ed affidandomi ad un piú "snello" trio Mvc, Json e WebClient, ho raggiunto il mio scopo.

Come? Brevemente...
Creo un' applicazione server basata su ASP .NET MVC (consiglio almeno la versione 3.0), che espone una serie di Controllers; questi ultimi contengono Actions che emettono i nostri oggetti "Poco", in formato Json. Le action devono essere organizzate in maniera adeguata per permettere la comunicazione bidirezionale: alcune rispondenti a verb GET (per l'emissione dei dati), altre a POST (per accettare oggetti Poco in ingresso e ricevere i dati).

Sul client useremo WebClient per invocare queste action presenti sul server, naturalmente usando l'opportuno verb.

Per la serializzazione e deserializzazione dei dati ricevuti ed inviati, faremo uso della libreria opensource Json.net (la migliore in assoluto per questo scopo, a mio parere).

Il resto della struttura é solo un po' di organizzazione per permettere di interagire con il server (dal client) in maniera coerente e omogenea. In questo senso, saró piú prolisso nel prossimo post...

Se riuscite anche solo ad immaginare il risultato, vi posso garantire che il problema delle performance é stato totalmente risolto. Pensate solo che una operazione, che Con vecchio sistema impiegava circa 10-12 secondi per essere completata, scende a 0,3 secondi...

Nessuna magia; solo la consapevolezza di aver risolto un problema (il trasporto dei dati) in maniera piú semplice e lineare,  scomponendolo nelle sue problematiche di dettaglio, ed applicando il giusto strumento per ciascuna di esse.

Detto cinese:
"Regalate un pesce ad un affamato e lo avrete salvato per un giorno; insegnategli ad usare una canna da pesca, e non avrá mai piú fame"

M.