Corrado Cavalli ci presenta WCF RIA Services illustrandoci come questa tecnologia ci permetta di realizzare applicazioni LOB con Silverlight in maniera RAD. L’insieme della parte di presentazione e la parte che sta sul server rappresenta la classica Rich Internet Application, il che significa avere a che fare con applicazioni n-tier.
Alcuni aspetti problematici da gestire
risolvere questi problemi rappresenta uno sforzo non indifferente, possiamo però usare i RIA Services per semplificarci la vita. Parliamo di un insieme di framework, tools e servizi per la semplificazione delle problematiche RIA
-
Data Shaping (Paging, Sorting, Filtering)
-
Rules (Validazone, Autorizzazione, User Settings, Concorrenza)
-
Ottimizzazioni (invio batch di dati al server9
Lo scopo è rendere fruibili le operazioni e le entità di business nella maniera più semplice e naturale possibile. Cosa da non sottovalutare è che non sono legato da uno specifico data acces (però usare EF & L2S aiuta!). Per utilizzare subito questa tecnologia basta scaricare i WCF RIA Service per Visual Studio 2010 Beta 2.
Corrado ci mostra subito una demo, realizzando un catalogo musicale (il suo commento: perlomeno non ho usato northwind…:D) (per la demo vi rimando ai video delle sessioni che saranno disponibili nei prossimi giorni).
Come funziona? Viene creata un’infrastruttura che lega client e server:
-
Runtime via WCF
-
Statico (Code generation e Shared code via Visual Studio)
-
il legame è trasparente per lo sviluppatore
-
Enable .NET RIA Services link in Visual Studio
Il punto cruciale è la classe DomainService, che rappresenta l’insieme delle operazioni CRUD messe a disposizione lato server. Può essere autogenerata da Visual Studio, possiamo usare LinqToSqlDomainservvice e LinqToentitiesDomainService. L’altro oggetto cruciale è il DomainContext che è la versione lato client del DomainService, che ci offre un insieme di elementi quante sono le entità esposte dal servizio, un oggetto EntityQuery<T> quante sono le operazioni di lettura espose dal servizio, il metodo load(EntityQuery<T>) che esegue la query invocando il relativo metodo del server, rejectchange e submitchange. E’ fortemente basato su delle convezioni, ad esempio ogni metodo del servizio che torna un’entità genera una query GetXXX e ReturnXXX, deve ritornare <T>, IEnumerable<T> o IQueryable<T>.
Ad ogni tipo esposto dal DomainService possono essere associati dei metadati che controllano la generazione lato client:
Posso usare degli attributi di validazione:
-
Required
-
StrinLenght
-
RegularExpression
-
Range
-
Display
-
Custom
Oltre alle classiche funzionalità di CRUD, possiamo invocare un qualsiasi metodo di business utilizzando l’attributo [Invoke] : il metodo così decorato rappresenta un mio classico metodo esposto con wcf (lato client diventa un metodo sul context). se voglio che il metodo sia invocato alla SubmitChanges uso l’attributo [Update] sul metodo.
La unit of work viene elaborata secondo questa sequenza:
-
Submit – riceve il changeset
-
authorizeChangeSet – verifica i permessi
-
ValidateChangeSet – esegue la validazione
-
ExecuteChangeSet – esegue le operazioni
-
PersistChangeSet – invoca la submit del context
-
ResolveChangeSet – processa le unit che hanno avuto problemi di concorrenza
tutti virtual che posso overridare. Un ulteriore attributo, [Resolve], permette di definire la nostra logica di risoluzione della concorrenza. E’ possibile inolte utilizzare lo stesso meccanismo di autenticazione, ruoli e profili di ASP.NET. lato client la parte di autorizzazione è esposta da WebContext.
Tutti i domain services in una web application generano il relativo context, quindi se ho due applicazionni silverlight che usano i miei servizi possono realizzare una ria services class library e referenziarla nella mia applicazione silverlight.
Perdonate eventuali imprecisioni ma era difficile seguire e scrivere conteporaneamente! Vi lascio con una foto emblematica del risultato della sessione:
