Java  »  Articoli  »  Accesso ai dati, Hibernate e database 

Una delle esigenze che uno sviluppatore software dovrebbe maggiormente sentire, quando si parla di interazione tra utente e macchina, è quella di rendere l'esperienza del primo, il meno complessa possibile. La complessità non risiede solo nell'organizzare le informazioni in maniera adeguata, ma anche il tempo con cui queste informazioni vengono raccolte e visualizzate.

Lo sviluppo di applicazioni web based è affiancato tipicamente da una base di dati dalla quale caricare le informazioni che l'utente richiede. In questo articolo cercheremo di comprendere come realizzare uno strumento che riduca il numero di accessi alla base di dati, avendo come effetto principale quello di velocizzare la visualizzazione delle informazioni.

Un buono progettista di software sa che un DBMS è un sistema che gestisce in maniera semplice e standard le operazioni sui dati, e sa anche che ogni volta che ci si accede c'è un buona quantità di risorse di sistema che vengono impegnate per svolgere la funzione richiesta. In gergo si dice che il DBMS è un collo di bottiglia, cioè, il flusso di esecuzione viene rallentato (al momento della chiamata). Spesso in fase di scelta della configurazione si preferisce dedicare maggiori risorse (finanziarie, soprattutto) per acquistare DBMS più veloci e potenti, trascurando il dettaglio che dei semplici accorgimenti software possono incrementare la velocità a costo zero.

La cache, cioè uno strumento che mantiene in memoria volatile dati utilizzati frequentemente dall'applicazione. Diciamo subito che vedremo una semplice soluzione adattabile in maniera immediata a ogni contesto applicativo, mentre esistono strumenti e framework che ne gestiscono i dettagli avanzati in maniera completa.

Analisi e disegno del progetto

Lo scenario d'uso cui faremo riferimento è quello di una tipica applicazione web, dove è l'utente a effettuare delle ricerche (con un modulo di ricerca testuale) su una base di dati. Uno scenario piuttosto comune in applicativi web based.

Per semplicità supponiamo anche che l'utente possa decidere se forzare l'accesso sulla base di dati (in modo da valutare la differenza di tempo tra il primo e il secondo metodo).

Avremo un layer di persistenza gestito con una classe che avrà il metodo di accesso per la ricerca (ci atteniamo allo scenario definito). Il client di questa classe deve avere trasparenza rispetto alla cache, quindi, il client deve conoscere il comportamento astratto.

Possiamo già identificare la classe astratta Database e quella concreta DatabaseConcrete. Quest'ultima, però, deve occuparsi esclusivamente di gestire le operazioni di persistenza, senza altri compiti. Una terza classe, la cache, quindi, mantiene il riferimento a un DatabaseConcrete e mantiene in memoria le informazioni rilevanti in una struttura dati, inoltrando le richieste verso il DatabaseConcrete. La classe cache (o proxy) DatabaseProxy presenterà gli stessi metodi della classe Database, quindi può ereditare da essa agendo da intermediario tra il client e il DatabaseConcrete. Tutto trasparente al client, che comunicherà con il tipo astratto Database.

Altri articoli

Altre guide

Altre newsletter