Acquisire profonda conoscenza del pattern MVC e dei principali J2EE design patterns
Sviluppare un'applicazione web è un compito piuttosto complesso viste le notevoli variabili in gioco, l'insieme di competenze richieste e i possibili fattori di criticità. Progettarla e svilupparla bene è un compito assai più arduo perché richiede un maggiore sforzo nella fase concettuale di progettazione, ripagato senza ombra di dubbio dagli innumerevoli vantaggi che un'applicazione ben fatta porta con sé. Non c'è miglior modo per avvicinarsi in maniera corretta al disegno di un'applicazione che sfruttare l'esperienza e gli sforzi di chi ci ha preceduto e di chi conosce meglio di noi la tecnologia che andremo ad usare. Lo studio dei design-patterns ci aiuta in questo, poichè ci propone soluzioni sperimentate e funzionanti a problemi ricorrenti nella gran parte dei progetti.
E' fondamentale quindi avere ben chiaro cosa voglia dire strutturare un'applicazione secondo il pattern MVC, fondamentale per la comprensione di Struts, ed è importante avere presente tutti gli altri pattern fondamentali. Per chi è interessato è consigliabile la lettura alla seguente pagina del sito Sun.
(http://java.sun.com/blueprints/patterns/catalog.html)

Disegnare l'applicazione prima di svilupparla
E' purtroppo pratica comune lanciarsi a scrivere centinaia di classi Java e pagine JSP senza avere un disegno in testa e quindi accorgersi di aver scritto codice ridondante, inefficiente e spesso da sostituire il giorno prima del rilascio del progetto (o magari poco prima…). E' bene quindi compiere uno sforzo nella fase di disegno del progetto che porti quanto meno ad una modellazione tramite classi delle principali entità coinvolte e delle loro interazioni . Anche se questo consiglio può sembrare ovvio e quindi banale , l'esperienza insegna che questa è proprio la fase più comunemente trascurata nei progetti, specialmente dove non c'è una cultura di base che porti ad apprezzare i benefici di una corretta analisi object-oriented. Il fattore tempo è sempre quello più critico nello sviluppo dei progetti e spesso non si riesce a far comprendere quanto il tempo impegnato nel disegno riduca bruscamente i tempi legati a riscritture di codice sbagliato, correzione di bug o manutenzione.
Pensare cosa fare prima di farlo almeno in questo ambito è spesso consigliabile.

Non inserire logica applicativa nelle pagine JSP e nelle Action
Struts è un framework che indirizza lo sviluppo per lo strato di controller dell'applicazione e fornisce un aiuto mediante i suoi custom-tags nello sviluppo della view. Non interviene invece nella scelta implementativa dello strato di Model. E' quindi buona norma non inserire logica applicativa nelle Action né tantomeno nelle pagine JSP. La logica applicativa è parte del Model indipendentemente da come questo venga realizzato, semplici classi Java, EJB, o altro.
Il Model non deve avere conoscenza di Struts, ovvero non bisogna mai passare al model riferimenti ad oggetti facenti parte del framework. Così facendo si renderebbe il proprio strato di business-logic dipendente da Struts e quindi inutilizzabile in altri contesti.
Ogni livello dell'applicazione deve svolgere il compito a cui è destinato. Il destino delle Action non prevede la logica applicativa.

Non inserire scriptlet nelle pagine JSP
Gli scriptlet nella terminologia JSP sono degli elementi di codice Java inseriti nelle pagine JSP tra <% e %>. E' tendenza degli sviluppatori più inesperti fare largo ricorso a questi ultimi nello sviluppo delle pagine conducendo così la propria applicazione verso risultati disastrosi. Le ragioni di questa affermazione sono molteplici. Innanzitutto il codice di una pagina JSP piena di scriptlet è poco comprensibile quindi di difficile manutenzione, motivo che di per se stesso ne sconsiglierebbe l'uso. Inoltre così facendo si tende ad inserire logica nelle pagine ricadendo nell'errore già evidenziato al punto 2). Ma la cosa peggiore, che chi viene dal mondo della programmazione procedurale stenta ad apprezzare, è il fatto che così facendo non si utilizzano le potenzialità legate alla natura object oriented del linguaggio Java, ovvero non si fa uso di tecniche quali polimorfismo ed ereditarietà che sono la vera potenza di un linguaggio OO e che portano ad un migliore riuso della logica della propria applicazione. Tra l'altro con l'introduzione della JSTL e del Expression Language è oggi praticamente possibile fare tutto in una pagina JSP senza ricorrere a scriptlet. Tanto è vero che nella versione JSP 2.0 la Sun ha introdotto un attributo che consente addirittura di disabilitare gli scriptlet stessi.
Se pensiamo quindi di avere una buona ragione per inserire uno scriptlet in una pagina JSP, nel 99% dei casi stiamo commettendo un errore.

Mai effettuare link diretti a pagine JSP
Come ormai noto noto Struts è costruito secondo una architettura MVC, nella quale è previsto un controller centralizzato che esegue le elaborazioni di tutte le richieste.
A tale scopo è assolutamente sconsigliato effettuare link diretti tra pagine JSP della propria applicazione. Link di questo tipo aggirando il controller portano ad una violazione del modello che può essere molto pericolosa. Se ad esempio nel controller centralizzato abbiamo messo un qualche tipo di controllo di sicurezza, queste pagine ne saranno prive e costituiranno un problema per la propria applicazione.

Suddividere in più parti lo struts-config.xml
Uno dei principali problemi nello sviluppo di grossi progetti con Struts è la notevole dimensione del file di configurazione struts-config.xml. Per evitare questo problema è meglio suddividere la propria applicazione in moduli. Non abbiamo affrontato precedentemente questo argomento, ma è molto semplice farlo seguendo i suggerimenti riportati alla pagina:
http://struts.apache.org/userGuide/configuration.html#dd_config_modules
Altrimenti è possibile usare un semplice trucco. Suddividere il file in più parti indicando nel web.xml nella dichiarazione dei parametri della ActionServlet la lista dei file di configurazione utilizzati separati da una virgola.

Gestire in modo dichiarativo le diverse parti dell'applicazione
Struts da la possibilità di gestire in modo dichiarativo, quindi senza modificare il codice, diversi elementi della propria applicazione. Inutile ripetere i vantaggi in termini di flessibilità e facilità di modifica di questo approccio rispetto a quello programmatico. Quando è possibile quindi gestire sempre in modo dichiarativo componenti quali le eccezioni o i controlli formali dei campi di input dei form tramite il Validator.

Utilizzare la DispatchAction invece della Action
Un altro grosso problema nello sviluppo con Struts è il proliferare di classi Action. A tale scopo è preferibile usare sempre la DispatchAction che consente di raggruppare in unica classe diverse operazioni tra loro logicamente correlate. Ciò porta ad una migliore organizzazione del progetto e ad una più efficiente strutturazione del codice.

Utilizzare proprie classi base
Chiunque abbia mai sviluppato una applicazione J2EE con Struts sa bene che ci sono una serie di operazioni comuni e ripetitive che tutte le Action eseguono (il concetto vale in generale ovviamente per qualsiasi applicazione anche se non si parla di Action). Stessa cosa vale per gli attributi degli ActionForm che spesso sono ridondanti tra i vari form-bean della propria applicazione. E' utile pensare ad una propria gerarchia di classi realizzando ad esempio una propria Action base che contenga l'implementazione di tutti i metodi comuni, magari astratta in modo che fornisca anche una struttura comune a tutte le Action del progetto dichiarando metodi standard da implementare. Stessa cosa è possibile fare per gli ActionForm sviluppando una ActionForm base e evitando inutili duplicazioni di attributi.
10) Usare le JSTL in luogo dei tag di Struts quando possibile
Come sappiamo Struts fornisce una serie di propri custom-tag utili a differenti scopi. Nella libreria standard di tag di Java, la JSTL (Java Standard Tag Libraries), ci sono tag che svolgono le stesse funzionalità dei tag di Struts. In tal caso è sempre bene preferire i tag JSTL che sono standard e saranno supportati in tutte le future versioni JSP. Ad esempio il discorso vale per la libreria logic di Struts che è completamente sostituita dalla libreria core delle JSTL, libreria che sostituisce in parte anche la bean di Struts. Gli unici tag di Struts che ancora hanno una notevole utilità sono i tag della libreria html almeno finchè le Java Server Faces non si saranno affermate come tecnologia di riferimento per la costruzione degli elementi grafici delle pagine web.

Conclusioni
In questo articolo abbiamo elencato alcuni punti significativi da tenere presente nello sviluppo di applicazioni J2EE con Struts. Ovviamente ci vorrebbe un libro intero per elencare tutti i possibili trucchi e le possibili soluzioni ai vari problemi che si incontrano nello sviluppo quotidiano con Struts. La cosa importante al termine di questa lunga serie di articoli è riuscire ad apprezzare i vantaggi che possono scaturire nello sviluppo con un framework e i benefici che può apportare Struts che tra i framerwork J2EE è sicuramente quello più largamente usato ed apprezzato.
La speranza è che tutto quanto scritto possa essere di utilità a tutti coloro che giorno per giorno si cimentano con l'arduo ma affascinante compito dello sviluppo di applicazioni web.

Bibliografa
[1] Chuck Cavaness - "Programming Jakarta Struts", O'Reilly, 2003
[2] James Goodwill, Richard Hightower - "Professional Jakarta Struts" - Wrox 2004
[3] Richard Hightower - "Jakarta Struts Live" - SourceBeat 2004

Alfredo Larotonda, laureato in Ingegneria Elettronica, lavora da diversi anni nel settore IT. Dal 1999 si occupa di Java ed in particolare dello sviluppo di applicazioni web J2EE. Dopo diverse esperienze di disegno e sviluppo ora si occupa in particolare di aspetti architetturali per progetti rivolti al mercato finanziario ed industriale. E' in possesso delle certificazioni SCJP (Sun Certified Java Programmer), SCWCD (Sun Certified Web Component Developer) e SCBCD (Sun Certified Business Component Developer).