21. Conclusione

Ricordiamo quanto illustrato in questo documento:

• le basi della programmazione web in Java con i servlet e le pagine JSP
• un'introduzione all'architettura MVC
• un'introduzione all'architettura a tre livelli
• un'introduzione a Spring IoC
• esempi a illustrazione di questi punti

Riteniamo che il lettore che è arrivato fin qui sia pronto a sviluppare autonomamente le proprie applicazioni web in Java. È inoltre pronto ad affrontare altri metodi di sviluppo simili a quelli studiati in questo documento. Ricordiamo l’architettura delle applicazioni web sviluppate in questo documento:

Per applicazioni semplici, questa architettura è sufficiente. Dopo aver scritto diverse applicazioni di questo tipo, ci si rende conto che i servlet di due applicazioni diverse:

1. utilizzano lo stesso meccanismo per determinare quale metodo [doAction] debba essere eseguito per elaborare l’azione richiesta dall’utente
2. differiscono in realtà solo per il contenuto di tali metodi [doAction]

La tentazione è quindi forte di:

• fattorizzare l’elaborazione (1) in un servlet generico che non conosce l’applicazione che lo utilizza
• delegare l’elaborazione (2) a classi esterne, poiché il servlet generico non sa in quale applicazione viene utilizzato
• collegare l’azione richiesta dall’utente alla classe che deve elaborarla tramite un file di configurazione

Sono stati sviluppati degli strumenti, spesso denominati «framework», per fornire agli sviluppatori le funzionalità sopra descritte. Il più antico e probabilmente il più noto tra questi è Struts (http://struts.apache.org/). Jakarta Struts è un progetto dell’Apache Software Foundation (www.apache.org). Questo framework è descritto in (http://tahe.developpez.com/java/struts/).

Apparso più di recente, il framework Spring (http://www.springframework.org/) offre funzionalità analoghe a quelle di Struts. Si tratta in realtà del suo modulo Spring MVC. Il suo utilizzo è stato descritto in diversi articoli (http://tahe.developpez.com/java/springmvc-part1/).

Spring non si limita al solo concetto MVC del livello [web] di un’applicazione a tre livelli. È utile anche in applicazioni al di fuori del web.

Abbiamo quindi concluso il nostro corso implementando un’architettura MVC in un’architettura a tre livelli [web, metier, dao] su un esempio di base di gestione di un elenco di persone.

Nella versione 1 dell’applicazione, l’elenco delle persone era mantenuto in memoria e scompariva alla chiusura dell’applicazione web. Nelle altre versioni, l’elenco delle persone è conservato in una tabella del database. Abbiamo utilizzato quattro diversi SGBD: Firebird, Postgres, MySQL e SQL Server Express.

Grazie a Spring IoC, il livello [web] della versione 1 è stato mantenuto integralmente nelle versioni successive. Abbiamo così dimostrato che è possibile costruire architetture ntier con livelli indipendenti.

Con le versioni che utilizzano un database, abbiamo illustrato il contributo di Spring alla realizzazione dei livelli [dao] e [service]. Grazie all’integrazione di Spring con iBATIS, siamo riusciti a realizzare quattro versioni che differiscono solo per i file di configurazione. La stessa classe [DaoImplCommon] è stata utilizzata per implementare il livello [dao] in tutte e quattro le versioni. Per gestire un problema specifico di SGBD Firebird, abbiamo dovuto derivare questa classe, ma senza modificarla.

Infine, abbiamo illustrato come Spring ci consentisse di gestire le transazioni in modo dichiarativo a livello del livello [service].

Il lettore è invitato a scoprire tutte le funzionalità offerte da questo prodotto.