Che cos'è un'architettura a più livelli?

Completato

In un'architettura a più livelli l'applicazione è divisa in livelli logici e livelli fisici. La N rappresenta il numero di livelli fisici in cui è suddivisa l'applicazione, che in genere è correlato al numero di livelli. Si può avere un'architettura a due livelli (client-server) o anche a cinque livelli. È tuttavia consuetudine e spesso ideale non superare quattro livelli.

Vediamo da cosa sono costituiti i livelli logici e i livelli fisici.

Cosa sono i livelli logici?

Questi livelli separano in modo logico il codice dell'applicazione che costituisce un'applicazione. Ogni livello ha responsabilità specifiche, ad esempio gestire le richieste degli utenti, eseguire la logica di business o gestire l'archiviazione dei dati.

Quando si separa un'applicazione in questi livelli logici, si può gestire ogni livello logico in modo indipendente. Quando si separano i componenti dell'applicazione, diventano modulari e diventa più facile gestire l'applicazione. Si può ottimizzare l'applicazione per ogni responsabilità. Il livello di gestione delle richieste Web è incentrato sulla relativa attività principale: la gestione delle richieste Web. Non deve occuparsi dell'archiviazione dei dati o dell'esecuzione della logica di business. Il livello accesso ai dati è al contrario incentrato sull'ottimizzazione della comunicazione con l'archivio dati e non considera i dettagli relativi al modo in cui sono presentati all'utente. Questo concetto di concentrazione su funzionalità specifiche viene chiamato separazione dei compiti.

Ecco un diagramma che mostra i livelli logici in una normale architettura a più livelli. Ogni livello logico gestisce un singolo aspetto dell'applicazione. Il livello della logica di business gestisce la comunicazione tra il livello dell'interfaccia utente e quello dell'accesso ai dati.

Visualization of layers.

Che cosa sono i livelli fisici?

Questi livelli rappresentano la separazione fisica delle parti dell'applicazione in risorse di calcolo distinte. In linea generale, ogni livello fisico esegue un livello logico dell'applicazione.

La separazione dell'architettura in livelli fisici porta diversi vantaggi:

  • I componenti dell'applicazione possono essere scalati separatamente aggiungendo risorse a ciascun livello fisico.
  • L'applicazione può essere resa più resiliente, aggiungendo il bilanciamento del carico per rilevare eventuali risorse non funzionanti e reindirizzare le richieste a sistemi con stato integro.
  • L'applicazione può essere resa più sicura limitando la comunicazione di rete tra i livelli e consentendo solo l'accesso necessario.

L'architettura determina che la comunicazione tra i livelli deve essere in modo dall'alto in basso. Ogni livello può dialogare con il livello immediatamente sottostante, ma in genere non può saltare i livelli. Questa progettazione migliora la sicurezza in quanto limita la superficie esposta di un livello.

Visualization of tiers.

Architettura a tre livelli

Di tutte le architetture a più livelli, quella a tre livelli è la più comune. Le responsabilità e i nomi di ogni livello logico e fisico variano in base all'applicazione e all'azienda. Un'applicazione a tre livelli ha in genere un livello presentazione, un livello applicazione o intermedio e un livello dati. Questa architettura è lo stile di livello N più comune. Nel resto di questo modulo si farà riferimento a un modello a tre livelli con ogni livello che esegue un singolo livello dell'applicazione e verranno chiamati livelli sinonimi.

Livello presentazione

Il livello presentazione si occupa in genere delle richieste degli utenti. Può trattarsi di utenti che accedono a una pagina Web o dell'accesso pubblico all'applicazione attraverso un'API esposta. L'obiettivo di questo livello è l'esperienza utente. Offre quindi elementi come un'interfaccia intuitiva e garantisce comunicazioni sicure tra l'utente finale e l'applicazione.

In questo livello non si è interessati ai dati stessi, a parte il modo in cui vengono presentati all'utente. In questo livello in genere non si verifica l'elaborazione dei dati o l'accesso ai dati. Queste operazioni sono responsabilità dei livelli inferiori.

Livello applicazione

Il livello applicazione (spesso chiamato anche livello intermedio) si concentra in genere sulla gestione della logica di business dell'applicazione. Include ad esempio la gestione di un ordine del cliente, il tracciamento di una spedizione o l'aggiornamento dell'inventario in base ai materiali ricevuti. Questo livello è responsabile anche delle attività di creazione, lettura, aggiornamento ed eliminazione (CRUD) rispetto al livello dati. È anche una posizione ideale per effettuare chiamate a servizi dipendenti, ad esempio le API esterne.

Questo livello non si occupa di come le informazioni inserite vengono riproposte all'utente, né di come i dati vengono archiviati e recuperati. L'attenzione è posta sulla logica di business necessaria per soddisfare la richiesta che l'applicazione ha ricevuto.

Livello dati

Questo livello si concentra sull'archiviazione dei dati. L'archiviazione dei dati in tabelle, file o altri supporti è responsabilità di questo livello. Questo livello offre un'interfaccia (ad esempio T-SQL) per accedere ai dati. In un'architettura a tre livelli, il livello dati offre l'accesso ai dati al livello applicazione.

Questo livello non si occupa del modo in cui i dati vengono presentati all'utente, né della logica dei dati. L'utilizzo di stored procedure può risiedere in questo livello, ma la maggior parte della logica che riguarda i dati deve essere gestita in un livello superiore.

Quando usare le architetture a più livelli

Ora che è stato spiegato che cos'è un'architettura a più livelli, verranno descritti gli scenari in cui è utile usarne una. Prendere in considerazione un'architettura a più livelli per:

  • Applicazioni Web di piccole e medie dimensioni.
  • Migrazione di un'applicazione locale ad Azure con refactoring minimo.
  • Usando le competenze, le funzionalità e l'esperienza degli sviluppatori locali.

Le applicazioni Web sono un buon caso d'uso per le architetture di questo stile. A causa della ridotta complessità di questo stile di architettura e la separazione spesso naturale tra le responsabilità nelle applicazioni Web, le architetture a più livelli possono rappresentare un'ottima soluzione. Queste applicazioni possono essere rivolte al pubblico o applicazioni line-of-business usate internamente da un'organizzazione. Per le applicazioni più piccole o meno complesse, potrebbe essere sufficiente un'architettura a due livelli (client-server), con i livelli presentazione e applicazione combinati anziché separati.

Le architetture a più livelli sono comuni nelle applicazioni locali tradizionali, di conseguenza sono una scelta naturale per la migrazione di carichi di lavoro esistenti ad Azure. Le applicazioni in questo stile vengono spesso migrate in Azure con un refactoring minimo o poche modifiche. La migrazione iniziale risulta così più semplice. Per migliorare ulteriormente l'applicazione dopo averne eseguito la migrazione ad Azure, si può usufruire dei servizi PaaS (piattaforma distribuita come servizio).

Poiché si tratta di uno stile di architettura comune, gli ingegneri hanno spesso un alto livello di esperienza e di familiarità con questo stile. Scegliendo questa architettura, è possibile usare le competenze esistenti per distribuire le applicazioni senza imparare a usare nuovi modelli di architettura.

Verificare le conoscenze

1.

È necessario aggiornare un'applicazione a tre livelli per integrarla con l'API di un partner. In quale livello è consigliabile aggiungere questa funzionalità?

2.

In quale livello è accettabile consentire l'accesso agli utenti?