In Febbraio in Workshop "UGIdotNET feat. Community Tour" avevo segnalato i RIA services... tecnologia in crescita da maggio/giugno 2009, presentata in combinazione con VS2010 ma disponibile una versione (anche se al momento in beta) per VS2008. Recentemente ho provato ad applicarli in casi reali, o meglio ne sto studiamo l’applicazione per casi reali. Riporto dei feedback a caldo dopo un mesetto circa di test.
La filosofia dei Ria services mi piace. Abbattere la barriera della portabilità dei servizi WCF per favorire la comunicazione eclusiva .NET tra client (silverlight) e server (WCF) è decisamente una scelta che approvo nell’ottica che fondamentalmente le applicazione RIA sono – in linea di massima – da considerare delle vere e proprie estensioni dell’applicazione web. L’applicazione RIA in questo modo può godere facilmente del DataContext definito sul server su cui applicare delle query custom (tramite linq) senza obbligarci ad implementare per ogni micro caso d’uso un nuovo servizio lato server o modificare quelli esistenti. La query linq viene trasferira al server che poi viene applicata al DataContext effettivo (linq to entity, linq to sql, linq to nhibernate... etc).
Fondamentalmente lato server occorre avere un provider linq capace di applicare la query al sorgente effettiva; lato client è possibile pensare all’implementazione di controlli (in genere la griglia è la più gettonata) che aiutino l’utente ad analizzare i dati filtrando, ordinando e raggruppando su tutte i campi della sorgente! Un potenzialità che davvero fà gola e potenzialmente ad un prezzo di produzione basso.
Fatte le premesse, vediamo l’esperienza pratica.
Accesso al dato con database Oracle. Al momento due alternative DevArt (Linq to Oracle o Linq to EntityFramework) oppure Nhibernate (Linq to Nibernate). Linq to NHibernate sembra non funzionare al meglio in combinazione con le Expression create dai FilterDescriptor del DomainDataSource; la scelta si è quindi orientata a DevArt che sembra funzionare bene; davvero peccato perchè avrei preferito usare Nhibernate con il quale ho maggiore controllo sul mapping e saprei dove intervenire in caso di personalizzazioni. L’uso di strumenti come Linq To Oracle, Linq to Sql o Linq To EF mi fanno sentire un pò “ingabbiato” – stessa sensazione che ho con i DataSet tipizzati.
Ovviamente lato client (Silverlight) è poco pensabile realizzare proprie componenti per implementare griglie completamente filtrabili, ordinabili e raggruppabili e quindi si è preferito orientarsi su soluzioni terze-parti di case il cui core business è fare controlli. Ho valutato SyncFusion, ComponentArt e Telerik. L’ultima della lista è quella che giudico la migliore per funzionalità e documentazione, ma ahimè la quale non è completamente integrata ai RIA. Il raggruppamento e l’ordinamento sono di default trasferiti al server mentre la ricerca tramite filtri delle colonne è esclusivamente client-side e al momento è proposto un work-around per il trasferire l’operazione server-side: intercettare gli eventi di Filtering e popolare la collezione la collezione FilterDescriptors del DomainDataSource a cui la griglia è collegata... peccato che il controllo DomainDataSource proponga soluzione di filtro molto semplici che non supportano quelli implementati dalla RadGridView della Telerik.
In conclusione. I RIA Services mi sembrano una tecnologia davvero con alte potenzionalità ai fini di realizzare con poco effort interfacce utente molto potenti. Al momento i mattoni per comporre potenti RIA sono ancora acerbi... anche se molto promettenti.
o0O( non completamente soddisfatto dai test ma confidente nel futuro della tecnologia!)
posted @ martedì 4 maggio 2010 00:52