Il post sulle "superfici di contatto" ha avuto diversi feedback (speravo di più ad esser sincero...si parla parecchio di metodologie di sviluppo qui si UGIdotNET e quindi pensavo che l'argomento interessase ai più...boh), ed ha riportato in auge il dilemma "meglio un data access layer o delle procedure sul database tipo stored procedure?".
Beh, io qui dico la mia, sperando ancora un volta in un ampio feedback in modo da metter sul tavolo un pò di argomenti di discussione interessanti.
La mia idea è che non ci può essere un vincitore a questa domanda. Nessuna delle due opzioni è meglio dell'altra in senso stretto. Devono essere applicate tutte e due se possibile.
Dando per scontato che lo sviluppo di un data access layer è sempre ben visto, il problema è unicamente capire se, quando e come utilizzare degli oggetti di programmazione che stanno *sul* database. Normalmente non si utilizzano gli strumenti di programmazione messi a disposizione del DB (e con questo termine intendo Stored Procedure, Funzioni, Viste e via dicendo) perchè si desidera far si che l'applicazione che si sta sviluppando possa andare bene su qualsiasi database, anche un "semplice" flat-file.
Benissimo, l'idea è corretta...però quello che non mi piace è che quindi devo utilizzare SQL Server, ORACLE ecc ecc come se fossere un flat file. Non mi sembra il massimo dell'efficienza...anzi, per dirla tutta mi sembra di aver buttato via i soldi.
Ovviamente la prima osservazione a quanto detto riguarda la gestione delle transazioni e quindi il supporto delle proprietà ACID, nonchè le facilities di backup, amministrazione e via dicendo.
L'idea si sposta quindi a fare un qualcosa che funzioni bene sia su SQL, che su ORACLE che su DB2 ecc. ecc. Perfetto. Ma se cosi vogliamo dobbiamo rifarci obbligatoriamente all'ANSI SQL Standard, dicendo addio a feature interessanti come, ad esempio, i campi incrementali, e le varie peculiarità di ogni database. Dovrei quindi svilupparmi io un meccanismo per la generezione degli ID delle chiavi primarie (visto che non è sempre possibile, anzi quasi mai, utilizzare come chiavi primare delle chiavi naturali).
Ok, è un pò di fatica in più ma si può fare.
Ma per quanto riguarda il mantenimento dell'integrità sui dati? Dovrei svilupparmi anche quello. E per ciò che concerne la sicurezza? Dovrei svilupparmi anche quello.
Bene...alla fine che cosa ho creato? Un mio personale, piccolo RDBMS! Sicuramente un lavoro di cui essere orgogliosi ma....assolutamente necessario? Secondo me no.
Io avrei adottato (e adotto) questa strategia: creo un data access layer che, tramite il pattern Abstract Factory mi permette di creare tanti piccoli Data Access Layer specializzati per il database alla quale si rivolgono, ed di ognuno di questi utilizzo il massimo delle feature che mi vengono fornite. In questo modo ho un sistema che, anche se non è inizialmente compatibile con tutti i database lo può facilmente diventare, e, allo stesso tempo, so che sfrutterà al massimo ogni tecnologia che mi viene messa a disposizione.
Oltre al "semplice" sfruttamento efficiente della tecnologia degli RDBMS si ottiene anche un grande beneficio: quello di rendere in una certa misura indipendente il mio DAL dallo schema fisico del database. Anche sul database si può effettuare del refactoring...e sarebbe seccante se, dovendo cambiare leggermente lo schema in modo da ottenere un design migliore (magari per uno scopo esterno alla mia applicazione...ad esempio la generazione di un report con i Reporting Services), sia *obbligatorio* anche modificare il DAL. Certo, potrebbe essere una buona idea modificare anche il DAL per assecondare il cambiamento dello schema, ma dal mio punto di vista non deve essere una scelta obbligata.
Concludo dicendo che il tutto deriva dalla mia personale esperienza, ossia lo sviluppo di applicazioni web per intranet, extranet ed internet, che quindi non sono praticamente mai isolate ma devono prima o poi convivere e collaborare con altri sistemi. Credo che da altri punti di vista (lo sviluppo di pacchetti software ad esempio), quello che ho appena detto potrebbe non essere così condivisibile. E' per questo che sono interessato ai feedback. Per capire altre realtà.