Concetti chiave
Nota nella Figura 1-2 che ciascuno dei livelli dell’architettura è segnato come chiuso. Questo è un concetto molto importante nel pattern dell’architettura a strati. Un livello chiuso significa che quando una richiesta si muove da un livello all’altro, deve passare attraverso il livello sottostante per arrivare al livello successivo. Per esempio, una richiesta che proviene dal livello di presentazione deve prima passare attraverso il livello di business e poi al livello di persistenza prima di arrivare al livello del database.
Figura 1-2. Strati chiusi e accesso alle richieste
Perché allora non permettere al livello di presentazione di accedere direttamente al livello di persistenza o al livello del database? Dopo tutto, l’accesso diretto al database dal livello di presentazione è molto più veloce che passare attraverso un mucchio di livelli inutili solo per recuperare o salvare informazioni sul database. La risposta a questa domanda sta in un concetto chiave conosciuto come livelli di isolamento.
Il concetto di livelli di isolamento significa che i cambiamenti fatti in un livello dell’architettura generalmente non hanno impatto o influenza sui componenti in altri livelli: il cambiamento è isolato ai componenti all’interno di quel livello, e possibilmente un altro livello associato (come un livello di persistenza contenente SQL). Se permetti al livello di presentazione di accedere direttamente al livello di persistenza, allora i cambiamenti fatti all’SQL all’interno del livello di persistenza avrebbero un impatto sia sul livello di business che sul livello di presentazione, producendo così un’applicazione strettamente accoppiata con molte interdipendenze tra i componenti. Questo tipo di architettura diventa molto difficile e costoso da cambiare.
Il concetto di livelli di isolamento significa anche che ogni livello è indipendente dagli altri livelli, avendo così poca o nessuna conoscenza del funzionamento interno degli altri livelli nell’architettura. Per capire la potenza e l’importanza di questo concetto, considerate un grande sforzo di refactoring per convertire il framework di presentazione da JSP (Java Server Pages) a JSF (Java Server Faces). Assumendo che i contratti (ad esempio, il modello) usati tra il livello di presentazione e il livello di business rimangano gli stessi, il livello di business non è influenzato dal refactoring e rimane completamente indipendente dal tipo di framework di interfaccia utente usato dal livello di presentazione.
Mentre i livelli chiusi facilitano i livelli di isolamento e quindi aiutano ad isolare i cambiamenti all’interno dell’architettura, ci sono momenti in cui ha senso che alcuni livelli siano aperti. Per esempio, supponiamo che si voglia aggiungere un livello di servizi condivisi a un’architettura che contenga componenti di servizio comuni a cui accedono i componenti del livello di business (per esempio, classi di utilità per dati e stringhe o classi di auditing e log). Creare un livello di servizi è di solito una buona idea in questo caso, perché architettonicamente limita l’accesso ai servizi condivisi al livello di business (e non al livello di presentazione). Senza un livello separato, non c’è nulla che limiti architettonicamente il livello di presentazione dall’accedere a questi servizi comuni, rendendo difficile governare questa restrizione di accesso.
In questo esempio, il nuovo livello di servizi risiederebbe probabilmente sotto il livello di business per indicare che i componenti in questo livello di servizi non sono accessibili dal livello di presentazione. Tuttavia, questo presenta un problema in quanto il livello di business è ora obbligato a passare attraverso il livello dei servizi per arrivare al livello di persistenza, il che non ha alcun senso. Questo è un vecchio problema con l’architettura a strati, e viene risolto creando strati aperti all’interno dell’architettura.
Come illustrato nella Figura 1-3, il livello dei servizi in questo caso è marcato come aperto, il che significa che le richieste possono bypassare questo livello aperto e andare direttamente al livello sottostante. Nell’esempio seguente, dato che il livello dei servizi è aperto, il livello di business è ora autorizzato a bypassarlo e ad andare direttamente al livello di persistenza, il che ha perfettamente senso.
Figura 1-3. Livelli aperti e flusso di richiesta
L’utilizzo del concetto di livelli aperti e chiusi aiuta a definire la relazione tra i livelli dell’architettura e i flussi di richiesta e fornisce a progettisti e sviluppatori le informazioni necessarie per comprendere le varie restrizioni di accesso ai livelli all’interno dell’architettura. L’incapacità di documentare o comunicare adeguatamente quali livelli nell’architettura sono aperti e chiusi (e perché) di solito risulta in architetture strettamente accoppiate e fragili che sono molto difficili da testare, mantenere e distribuire.