21. Conclusione

Rivediamo quanto è stato presentato in questo documento:

• le basi della programmazione web in Java utilizzando servlet e pagine JSP
• un'introduzione all'architettura MVC
• un'introduzione all'architettura a tre livelli
• un'introduzione a Spring IoC
• esempi per illustrare questi punti

Riteniamo che i lettori che sono arrivati a questo punto siano pronti a sviluppare le proprie applicazioni web Java. Sono inoltre pronti ad affrontare altri metodi di sviluppo simili a quelli trattati in questo documento. Esaminiamo l'architettura delle applicazioni web sviluppate qui:

Per applicazioni semplici, questa architettura è sufficiente. Una volta che avrete scritto diverse applicazioni di questo tipo, noterete che i servlet di due diverse applicazioni:

1. utilizzano lo stesso meccanismo per determinare quale metodo [doAction] eseguire per gestire l’azione richiesta dall’utente
2. in realtà differiscono solo per il contenuto di questi metodi [doAction]

La tentazione è quindi forte di:

• fattorizzare l'elaborazione (1) in un servlet generico che non sia a conoscenza dell'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 utilizzando un file di configurazione

Sono stati sviluppati degli strumenti, spesso denominati "framework", per fornire agli sviluppatori queste funzionalità. Il più antico e probabilmente il più noto tra questi è Struts (http://struts.apache.org/). Jakarta Struts è un progetto della Apache Software Foundation (www.apache.org). Questo framework è descritto all'indirizzo (http://tahe.developpez.com/java/struts/).

Il framework Spring (http://www.springframework.org/), emerso più di recente, offre funzionalità simili a quelle di Struts. Nello specifico, ci si riferisce al suo modulo Spring MVC. Il suo utilizzo è stato descritto in diversi articoli (http://tahe.developpez.com/java/springmvc-part1/).

Spring non si limita al 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 all'interno di un'architettura a tre livelli [web, logica di business, DAO] utilizzando un esempio di base di gestione di un elenco di persone.

Nella versione 1 dell'applicazione, l'elenco delle persone era conservato in memoria e scompariva quando l'applicazione web veniva chiusa. Nelle altre versioni, l'elenco delle persone è memorizzato in una tabella del database. Abbiamo utilizzato quattro diversi DBMS: Firebird, Postgres, MySQL e SQL Server Express.

Grazie a Spring IoC, il livello [web] della versione 1 ha potuto essere mantenuto integralmente nelle versioni successive. Abbiamo così dimostrato che è possibile costruire architetture n-tier con livelli indipendenti.

Con le versioni che utilizzano un database, abbiamo dimostrato il contributo di Spring alla creazione dei livelli [DAO] e [service]. Grazie all'integrazione di Spring con iBATIS, siamo stati in grado di realizzare quattro versioni che differiscono solo nei file di configurazione. La stessa classe [DaoImplCommon] è stata utilizzata per implementare il livello [dao] in tutte e quattro le versioni. Per risolvere un problema specifico del DBMS Firebird, abbiamo dovuto derivare questa classe, ma non è stato necessario modificarla.

Infine, abbiamo dimostrato come Spring ci abbia permesso di gestire le transazioni in modo dichiarativo a livello [service].

Invitiamo i lettori a esplorare tutte le funzionalità offerte da questo prodotto.