Accoppiamento tra un’applicazione Silverlight e l’accesso ai dati tramite WCF RIA Services

Devo essere onesto: quando per anni ed anni si parla di tutto tranne che di Web, e poi tutto ad un tratto si vuole cominciare, un po’ di imbarazzo lo si prova. Parliamo di Silverlight 4 e dei WCF RIA Services, disponibili con l’ultima versione del .NET Framework, Entity Framework e Visual Studio 2010. In giro per il web si trovano un sacco di tutorial e di video su come cominciare a realizzare un’applicazione Silverlight, che faccia accesso ai dati sfruttando le tecnologie citate nella frase precedente. Il mio dubbio – che cercherò di esporre nel modo più chiaro possibile – è quello di disaccoppiare ancora di più l’applicazione Silverlight vera e propria dalla sua parte Web, quella che “contiene” tutto ciò che serve per accedere ai dati. Vediamo di introdurre il discorso: lo screenshot qui sotto riporta il Solution Explorer di Visual Studio 2010, con una soluzione minimale (ed iniziale) di un’applicazione Silverlight 4. Nulla di particolare: l’assembly ApplicazioneCatalogo è l’applicazione Silverlight, mentre ApplicazioneCatalogo.Web contiene l’applicazione ASP.Net che si occupa di deployare la soluzione e di mostrare la pagina ApplicazioneCatalogoTestPage.aspx, che contiene al suo interno il plug-in di Silverlight. Nulla di nuovo. In questo momento non c’è alcun accesso ai dati. Per iniziare, dobbiamo fare essenzialmente tre cose:

1. aggiungere il data model di Entity Framework nel progetto ApplicazioneCatalogo.Web
2. compilare tutto quanto 😉
3. aggiungere una classe domain service nel progetto ApplicazioneCatalogo.Web

Per far ciò – o almeno per farle in pochi secondi – dovete avere un database a cui collegarvi. Compiuti i tre passi descritti qui sopra, avete una situazione simile a questa: Ho evidenziato in rosso i nuovi files aggiunti. A questo punto, se compilate tutto, accade una cosa strana: all’interno del progetto ApplicazioneCatalogo viene auto-generata una classe UtentiDomainContext. Dove? E’ semplice: per vedere questa classe basta andare su Project –> Show all files. Ecco che magicamente compare il file: Dentro quel ApplicazioneCatalogo.Web.g.cs è definita la classe UtentiDomainContext, che possiamo utilizzare ovunque noi vogliamo all’interno dell’applicazione Silverlight per accedere a tutte le entità di dominio definite nel data model DataModel.edmx. Ditemi quello che volete, ma a me questa soluzione non è che piaccia tanto. Funziona, è rapida, fa vedere come funzionano i WCF RIA Services, ma se devo sviluppare un’applicazione reale, non si può non osservare che c’è un forte accoppiamento tra l’applicazione e il provider di accesso ai dati. Per favore, se questo accoppiamento non c’è, trovate il modo giusto di farmelo capire! 🙂 Se fosse una classica applicazione client WPF, aggiungerei una banale class library – ApplicazioneCatalogo.DataProvider – che contiene tutta la logica di accesso ai dati. E magari in questo assembly farei un provider generico, che tramite factory o qualche IoC va ad istanziare il provider vero, contenuto magari in ApplicazioneCatalogo.DataProvider.EntityFramework, o ApplicazioneCatalogo.DataProvider.NHibernate, e così via. Invece c’è questo accoppiamento che – tra l’altro – non è realizzato tramite riferimento come accade di solito, ma tramite un’opzione raggiungibile nelle proprietà del progetto ApplicazioneCatalogo: La ComboBox che ho evidenziato non fa altro che puntare al progetto Web contenente il data model ed il domain service: impostazione che – dietro le quinte – genera la classe indicata prima. Con Silverlight questa cosa non è possibile: se aggiungo una class library, a questa giustamente non posso mettere nei riferimenti il progetto Web, e quindi siamo punto e a capo. L’unico modo che ho trovato in questo momento è quello di aggiungere una seconda applicazione Silverlight che funge da data provider. Osservazioni importanti:

1. WCF RIA Services link del progetto ApplicazioneCatalogo: <No Project Set>
2. WCF RIA Services link del progetto ApplicazioneCatalogo.DataProvider: ApplicazioneCatalogo.Web
3. L’assembly ApplicazioneCatalogo non sa che l’accesso ai dati avviene tramite Entity Framework: lui utilizza le classi esposta da ApplicazioneCatalogo.DataProvider, e nulla di più
4. All’interno dell’assembly ApplicazioneCatalogo non viene più generata la classe “nascosta” UtentiDomainContext, a riprova del punto (3)
5. A questo punto, non mi resta che scrivere il mio data provider dentro ApplicazioneCatalogo.DataProvider, che può utilizzare EF oppure no, e qualsiasi cosa faccia, lo faccia tramite factory, IoC e compagnia bella

L’unica cosa che non mi piace è che sono abituato ad avere riferimenti tramite assembly dll, mentre con tutto il discorso qui sopra l’applicazione principale (ApplicazioneCatalogo) ha un riferimento al data provider (ApplicazioneCatalogo.DataProvider): quest’ultima tecnicamente parlando è un’altra applicazione, un file XAP insomma. Che ne dite, mi sono spiegato?

Send to Kindle