< Home
Stampa

Architettura di una applicazione SpringBoot

Sommario

Con SpringBoot è possibile realizzare molti tipi di applicazioni:

  • WebServices e Web sites anche tramite microservizi;
  • Applicazioni di grandi dimensioni per la gestione di banche dati (server to server);
  • Applicazioni per l’elaborazione automatica di dati (ETL, migrazioni, ecc.);
  • Applicazioni desktop (con Electron)
  • Sistemi real-time (per esempio per IoT o domotica)
  • Applicazioni cloud serverless (come Lambda)

In queste lezioni ci occuperemo principalmente di Web Service, un tipo di Web Application.

Struttura applicativa di una Web Application

Un Web Service è una Web Application, ovvero una applicazione lato server che ha il ruolo di backend di un Web Server. A sua volta la Web Application si appoggia, per la persistenza dei dati, ad un sistema di database esterno che permette di memorizzare e ricercare i dati su un database.

Lo schema è dunque il seguente:

Il Web Server in realtà può essere sia interno che esterno all’applicazione SpringBoot:

  • se interno, SpringBoot compilerà un Jar che conterrà quindi entrambi gli applicativi, sia il Web Server (Apache Tomcat) che la Web Application associata. Questa soluzione è indicata per avere soluzioni all-in-one.
  • es esterno, SpringBoot crea un War con la sola Web Application, che andrà poi installata su un Web Server esistente. Questa soluzione è quella indicata quando dietro allo stesso Web Server sono collegate diverse Web Application.

Architettura di un Web Service

Un Web Service Springboot è di norma con una una architettura a 3 layer, dove ogni layer ha una precisa responsabilità applicativa:

  • i controllers definiscono le URL ed i servizi erogati, si occupano di gestire le richieste HTTP, chiamare il layer sottostante per eseguire le operazioni, e costruire la risposta per il client. Si occupano poi della sicurezza.
  • i services eseguono la business logic, cioè la logica ad alto livello dell’applicazione, e accedono ai dati del livello sottostante.
  • Il model/repository invece gestisce i dati e le loro relazioni, insieme alla logica necessaria per caricarli e salvarli nel database, attraverso la libreria JPA/Hibernate di Java EE (esistono comunque delle alternative che consentono l’accesso diretto al database).

Sono poi previsti dei moduli di supporto:

  • le utilities sono delle classi di supporto alla business logic
  • analogamente, gli helpers sono classi di supporto ai controllers

Questo schema può essere riassunto graficamente in questo modo (le frecce indicano le dipendenze):

I dati sono rappresentati sia del Model, che rappresenta le entità del dominio di informazione dell’applicazione, e dai Data Transfer Object, oggetti senza funzioni che sono utilizzati per trasferire dati attraverso i layers. Questo tipo di struttura è utilizzata nella maggioranza dei servizi web, con eventuali varianti.