In questi giorni da un cliente mi sono trovato a dover
spiegare perchè è cosa buona e giusta creare uno strato di accesso ai
dati e perchè è necessario utilizzare abbondantemente stored procedure e
affini (se presenti nell'rdbms utilizzato).
Sul momento ho spiegato per esteso le varie problematiche che tale soluzione
permette di evitare, correggere e prevenire, ma, ora, ripensandoci bene, credo
che la cosa potrebbe essere resa molto più chiara e comprensibile (e soprattutto
convincente) utilizzando un semplice concetto.
Tale concetto è ben rappresentato dall'idea di
pensare a delle "superfici di contatto ". Database e applicazioni,
applicazioni ed altre applicazioni, quando devono lavorare insieme devono per
forza di cose integrarsi condividendo alcuni dati. Possiamo immaginare l'insieme
di questi dati come un superficie; tale superficie di contatto
rappresenta il punto critico dell'insieme perchè, così come succede nella realtà fisica
delle cose, essa produce (o può produrre se non ben oliata) attrito,
che in termini informatici può essere definito come la quantità di
decadimento delle prestazioni dovuta alla presenza di tale superficie e del
relativo contatto tra le parti.
L'attrito è provato dallo "sfregamento" di tali
superfici: questo avviene soprattutto quando dobbiamo cambiare un'applicazione
per adattarla ai nuovi requisiti di business, ma dobbiamo farlo tenendo d'occhio
anche tutte le altre applicazioni che ne utilizzano i servizi (questo problema
è molto marcato in particolare nel campo dei database, dove modifiche
e refactoring sono piuttosto ardui).
Il nostro compito, quindi, in qualità di sviluppatori e di dba (agili 
),
è quello di ridurre al minimo tale
superficie di contatto: tramite un data access layer riduciamo enormemente
la superficie esposta dalla nostra applicazione (ed in più ci garantiamo
anche la possibilità di sostituire tale "panello" in modo molto veloce e poco
traumatico per l'applicazione); con delle stored procedure facciamo la stessa
cosa sul db, evitando che la superficie di contatto sia rappresentata dalle
tabelle stesse, che altrimenti, nel caso dovessere essere modificate,
produrrebbero troppo attrito (visto che dovremmo andare pensatemente di trigger
se non vogliamo / possiamo modificare lo strato di accesso ai dati
dell'applicazione che ne fa uso...sempre che ce ne sia uno...)
Che ne pensate? Gradirei molto i commenti di tutti, per capire se tale
concetto può essere valido, se siete d'accordo, oppure se pensate che abbia detto
un sacco di stupidate.
powered by IMHO 1.2