E’ da un pò che sto preparando un post dove volevo parlare e fare un punto della situazione - a grandi linee - dell'evoluzione che ha avuto l'architettura software e in particolare il mio modo di impostare le architetture… fare il punto su quali mode ho seguito - per scelta o imposizione - e dove vorrei andare. Ecco la mia evoluzione nel disegno archietturale seguendo la scia dell'evolzioni recentemente raccontate "L'evoluzione Architettonica e Tecnologica nel mondo dell'IT" e "Storia dei linguaggi di programmazione" .
Quando ho iniziato ad occuparmi di IT in maniera professionale - nel 1998 - l'idea di applicazione era quella di monolite procedurale (il client) da agganciare ad un database (il server). Stavano nascendo – o forse meglio dire stavo prendendo piede - le prime applicazioni desktop dopo che i gestionali in ambiente host (AS400 e compagnia) l’avevano fatta da padrone negli anni prima.
Le evoluzioni successive avevano come obiettivo quello di isolare la parte di accesso al dato dal resto dell'applicazione. Era il periodo delle data access e dei driver odbc e dei moderni provider oledb. Ma alla base di tutto ci sono sempre i database SQL e dannato o folle era chi usava istruzioni specifiche di un particolare DBMS. Parola d'ordine: sql standard - al bando le stored procedure! La filosofia che si voleva era che solo cambiando la stringa di connessione l’applicazione avrebbe switchato da un DBMS ad un altro.
Si iniziato poi a parlare di applicazioni distribuite e MTS, stava arrivando il web e la new economy! La nuova parola è tier e n-tier. Ancora non si parla di entità applicative e/o domini applicativi e il data tier è ancora legato a data access globali, SQL standard e i recordset vengono portati su su fino all'interfaccia. Sono gli anni dove nasce l'esigenza del recordset disconnesso (tanto odiato dagli amanti del recordset lato server)... poco più lento ma più maneggevole attraverso le "maglie" degli n-tier.
Un passaggio davvero interessante è infine l'introduzione dei data provider, della logica delle factory e delle componenti a Plug In (avevo scritto "Archietture a plugIn, pensieri e considerazioni"). L’introduzione in varie fasi e modalità dei Data Provider applicativi ha reso possibile un legame più debole verso la tecnologia di accesso al dato e perché no anche della forma della base dati. Il problema è ora il data mapping subito affrontato con l'introduzione di librerie/framework di persistenza del dato di cui tanto si parla anche oggi. Il problema dell'accesso al dato, la struttura del dato stesso e l'origine dei dati diventa un problema secondario da incapsulare nei data provider! I data provider danno una svolta nuova al modo di vedere l'accesso al dato e danno la possibilità di introdurre – con più facilità - il testing unitario (vedi mock/fake data provider). E' ora di abbandonare la DataAccess globale, di abandonare i limiti dell'uso di un SQL standard! E' ora possibile tornare ad usare le perculirità dei vari data base senza preoccuparsi della portabilità verso il basso perchè il cambio della fonte dati significa l’introduzione di un nuovo data provider senza dover cambiare – e nemmeno ricompilare - gli strati alti. Ovviamente c’è da pagare l’effort della riscrittura di un n uovo data provider (vantaggi e svantaggi della cosa credo che valgano un capito a se).
Dove voglio andare? Credo che che andare verso un modello a provider più spinto e non solo lmitato all’accesso al dato sia buona cosa. Non solo data provider ma spingere la parte pluggabile in alto fino alla parte business. Un buon esempio è la classe Membership dove I suoi metodi statici demandano la chiamata – salvo solo alcune basi validazioni sintattiche dei dati – al provider. La classe Membership risulta quindi essere una sorta di Façade del MembershipProvider che al suo interno non deve solo implementare la parte di accesso al dato ma può anche occuparsi di effettura proprie validazioni di Business… per questo il MemberShip provider non può essere classificato come un semplice Data Provider. Le applicazioni diventano quindi consumer di Façade di sistemi che gestiscono uno scope limitato e ben definito del business applicativo. I sistemi li vedo quindi divisi in Application Layer agganciati a sistemi a loro volta composti da Façade, Entità e definizione del provider…
Rimando all'articolo "Articolo sul Provider Model di ASP.NET 2.0" di Riccardo Golia per approfondimenti sull'uso del Provider Model.
Overview della mia evoluzione (immagine completa)
posted @ giovedì 3 agosto 2006 14:59