Il .net Framework 3.5 e Visual Studio 2008 hanno portato una ventata di novità nel mondo dello sviluppo .net. Linq, Entity Framework, le novità di ASP.net e molte altre cose utilissime e capaci di rendere più "snello" il lavoro di tutti i giorni. Tutte queste novità hanno però messo in ombra una grossa innovazione che è stata introdotta nei Dataset Tipizzati: i Dataset Distribuiti.
NOOO! Io odio i Dataset!
Fermi tutti! Se siete arrivati fino a qui ci sono due possibilità: o amate i dataset, o li odiate! E' proprio così, il Dataset, questo amato/odiato oggetto, è da sempre al centro della diatriba tra puristi dell'architettura e pragmatici del risultato. Io non sono pro o contro Dataset; questo ci tengo a dirlo subito. Semplicemente scelgo lo strumento più adatto allo sviluppo che deve essere intrapreso, tenendo in considerazione il maggior numero di parametri che mi possono aiutare durante la scelta, senza preconcetti.
Per taluni progetti, soprattutto semplici applicazioni Client-Server, il dataset è stato ed è un'ottima soluzione. Uno dei problemi di cui soffriva il dataset tipizzato era quello di immagazzinare in un' unica classe i dati relativi alle "Entità" (Tabelle) e all'accesso ai dati (TableAdapter). Questo, unito al fatto che in uno scenario di applicazioni distribuite per utilizzare le stesse entità tra il client (solitamente uno SmartClient) e l'applicazione server (Web Service) doveva per forza essere condivisa l'intera classe del dataset attraverso i vari "Tiers" applicativi, ha da sempre limitato l'uso del Dataset quale strumento per la realizzazione di applicazioni distribuite.
Molti di noi (me compreso) hanno trovato delle soluzioni a questo problema, ad esempio condividendo gli schemi xsd del dataset attraverso gli strati applicativi. Il problema maggiore, comunque, è rappresentato dalla mancanza di un ambiente integrato per una gestione "ragionata ed organizzata" del Dataset Distribuito.
Distributed DataSet: to the rescue!
Ma cos'è un Dataset Distribuito? E soprattutto, che cosa lo distingue da un Dataset tipizzato tradizionale? La risposta è semplice:
Un dataset distribuito è molto simile ad un dataset tipizzato, tranne per il fatto che tutte le entità che modellano le tabelle del nostro DB vengono collocate e compilate in un progetto, e quindi in una dll, separata rispetto al progetto nel quale viene implementato l'accesso ai dati.
Per scendere nel pratico, se creiamo un progetto Northwind.DataAccess, dobbiamo creare anche un progetto Northwind.Entities che conterrà le classi relative alle entità. Questo progetto viene mantenuto sincronizzato rispetto al progetto Northwind.DataAccess, in modo che alla variazione di tabelle (aggiunta di colonne) o all'aggiunta di tabelle stesse, il progetto Entities non perda coerenza. Tutto l'accesso ai dati che consiste in query e stored procedures, rimane completamente all'interno del progetto DataAccess.
Quest'ultima osservazione ci può far intuire come la dll Entities possa agevolmente essere utilizzata attraverso i vari tiers applicativi, con ovvi pro:
- in una applicazione SmartClient è possibile utilizzare, creando una referenza ad essa, la dll delle entità per sfruttare i meccanismi RAD di Visual Studio ed effettuare binding a design-time come se avessimo il Dataset disponibile localmente
- è possibile utilizzare le entità attraverso i tiers in modo trasparente, in quanto il dataset mantiene lo stato delle modifiche ad esso apportate atttraverso i vari tiers
- è possibile creare applicazioni completamente "tier-unaware", ovvero creando dei provider configurabili attraverso file di configurazione si riesce ad utilizzare lo stesso SmartClient in configurazione Client-Server o n-Tier senza dover modificare logiche di binding o dover riscrivere classi per effettuare lo stesso
Naturalmente, ci sono anche dei contro, peraltro abbastanza importanti:
- condividere classi attraverso i vari tier può essere limitante. Una modifica della classe ci obbliga a riaggiornare ogni strato che fa uso della dll contente le classi, e non sempre questo è possibile o consigliabile
- l'impiego dei Dataset non è "pulito" quanto l'impiego di un Domain Model (POCO)
- la semplicità e la trasparenza del sistema può invogliare a trasferire troppi dati tramite il Dataset, occupando così troppa banda. Il problema può essere mitigato se si progettano con attenzione quelli che poi saranno i metodi di scambio dati tra i tiers.
Conclusioni
In questa prima overview abbiamo chiarito le differenze tra un Dataset Distribuito ed un normale Dataset TIpizzato. Ci sono moltissime altre particolarità da vedere, ma cercheremo di sondarle nel prossimo articolo, assieme con la nostra soluzione per l'impiego effettivo dei dataset distribuiti.