In questo articolo intendo illustrare sinteticamente il funzionamento del framework Spring dietro le tende. Spring è uno strumento utilissimo, ma senza conoscere i suoi fondamenti non può essere usato e sfruttato appieno.
Questo articolo è un’integrazione alle lezioni che tengo nel “mondo reale” e non ha la pretesa di essere totalmente esaustivo.
Cominciamo: Spring si basa sulla tecnologia J2EE, che è uno standard di programmazione Java per il Web proposto dalla SUN all’inizio degli anni 2000. Dire che Spring “si basa” su J2EE è in realtà una forzatura, poiché il J2EE ha molti standard che Spring non riconosce o che ha completamente ristrutturato, in particolare mi riferisco agli Entity Java Beans (EJB), che Spring supera in modo brillante.
Spring fa uso delle Servlet, che sono uno dei tanti standard J2EE e hanno il compito di rispondere alle Request degli utenti. Lo standard J2EE prevede all’incirca una Servlet per ogni Request, mentre la peculiarità di Spring è che risponde a tutte le Request con un un’unica servlet: la Servelt Dispatcher.
Nello schema qui sopra possiamo vedere i passi che la DispatcherServlet compie a seguito di ogni richiesta:
- l’Handler Mapping analizza la richiesta e stabilisce quale Controller (e quale metodo!) sia preposto ad elaborare la request. Se nessun controller viene identificato viene sollevata un’eccezione 404.
- Viene quindi chiamato l’opportuno Controller ed eseguito il metodo desiderato.
- Il View Resolver è responsabile di capire che tipo di response debba essere creata ed eseguita. Normalmente ad ogni Response è associata una vista, tipicamente una vista thymeleaf. Ma potrebbe anche trattarsi di una Response JSON, contenente un oggetto.
- La View identificata, quindi, viene offerta sulla Request.
La Dispatcher Servlet, così come ogni altro componente di Spring, viene inizializzata all’interno di un contesto detto, appunto, Spring Context. E’ in questo contesto che il sistema “cerca” i bean o gli altri componenti richiesti dallo sviluppatore al fine di far funzionare l’applicazione.
Passiamo quindi a vedere, in sintetico dettaglio, le più comuni Annotation usate in Spring:
@Autowired
Questa Annotation è usata per chiedere a Spring di “iniettare” un’istanza di un particolare tipo laddove viene usata. Può essere usata su attributi o metodi anche in corrispondenza di interfacce o classi astratte. Questa annotation è un “clone” della più generica @Inject, introdotta con le specifiche JSR-330 ed è specifica di Spring.
@Bean
Un Bean è un componente che “vive” solo all’interno di uno specifico contesto e che può essere iniettato (con @Autowired o @Inject) a seconda del bisogno. E’ simile ad un component, ma è specifico per un contesto e non trasversale. Un Bean può essere definito solo in una classe etichettata come @Configuration.
@Component
E’ un’annotation molto generica, che si usa a livello di classe. Ogni elemento etichettato come @Component rientra automaticamente fra i componenti di Spring ed è disponibile ad ogni istanza di uno Spring Context. Molte annotation sono a loro volta etichettate come @Component, quindi sono esse stesse dei Component (ATTENZIONE: si tratta comunque di una relazione diversa dal extends).
@Configuration
Si tratta di un component che definisce dei tratti di configurazione.
@Controller
E’ un component. Identifica il front layer e definisce le route del sistema (con @RequestMapping).
@Service
E’ un component, ma si preferisce usare questa definizione per identificare la Business Logic.
@Repository
E’ un component, ma si preferisce usare questa definizione per identificare il Persistency Layer.