Superficie di contatto

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

Print | posted on Friday, January 28, 2005 6:05 PM

Feedback

# re: Superficie di contatto

Left by Simone Greci at 1/28/2005 7:04 PM
Gravatar Ciao Davide,
concordo pienamente con le tue affermazioni. Leggendo il tuo blog mi hai letteralmente illuminato, specialmente con il concetto di "Agile DBA".
Con l'articolo in questione hai usato una serie di paragoni molto validi: la scomposizione in layer è giusta, ma troppi fanno attrito! Bisogna sempre farei i conti con le performances e con la mantenibilità.

A presto ;)

Simone

# re: Superficie di contatto

Left by Andrea at 1/28/2005 11:46 PM
Gravatar Sempre illuminante...
E comunque la cosa la farò leggere anche a dei colleghi...

# re: Superficie di contatto

Left by Davide Mauri at 1/31/2005 8:33 PM
Gravatar Claudio non sei il solo a pensarla così, diverse persone sostengono la stessa cosa. Io la penso in modo diverso semplicemente perchè le stored procedure aiutano ulteriormente a diminuire la superficie di contatto, che, altrimenti, sarebbe tra il tuo data layer è l'*intero* database.
Il mio modo di approciare al problema è quello di creare *sia* il data layer, *sia* le stored procedure. Non sono due cose che si escludono a vicenda, sono due cose che si danno una mano l'una l'altra (Ovviamente sottointendo che nelle stored procedure non va messa logica business, ma solo il necessario per creare un'astrazione dello schema del db).
In ogni caso l'argomento è interessante e da approfondire...ora ne faccio un bel post!

# re: Ottimizzare codice TSQL.

Left by Alessio Marziali .NET at 9/28/2005 1:57 PM
Gravatar
Comments have been closed on this topic.

Copyright © Davide Mauri

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski