4. Sviluppo MVC (Model–View–Controller)

Un'applicazione web presenta spesso un'architettura a 3 livelli:

• il livello [DAO] gestisce l'accesso ai dati, il più delle volte dati persistenti all'interno di un DBMS. Ma questi possono anche essere dati provenienti da sensori, dalla rete, ecc.
• il livello [business] implementa gli algoritmi "aziendali" dell'applicazione. Questo livello è indipendente da qualsiasi forma di interfaccia utente. Pertanto, deve essere utilizzabile con un'interfaccia console, un'interfaccia web o un'interfaccia client avanzata. Deve quindi essere testabile al di fuori dell'interfaccia web, in particolare con un'interfaccia console. Questo è generalmente il livello più stabile dell'architettura. Non cambia se l'interfaccia utente o il metodo di accesso ai dati necessari per il funzionamento dell'applicazione vengono modificati.
• Il livello [interfaccia utente], ovvero l'interfaccia (spesso grafica) che consente all'utente di controllare l'applicazione e di ricevere informazioni da essa.

La comunicazione scorre da sinistra a destra:

• l'utente effettua una richiesta al livello [interfaccia utente]
• questa richiesta viene formattata dal livello [interfaccia utente] e trasmessa al livello [logica di business]
• se il livello [logica di business] necessita di dati per elaborare questa richiesta, li richiede al livello [DAO]
• ogni livello interpellato restituisce la propria risposta al livello alla sua sinistra fino a quando la risposta finale raggiunge l'utente.

Ai livelli [business] e [DAO] si accede normalmente tramite interfacce Java. Pertanto, il livello [business] conosce solo le interfacce del livello [DAO] e non è a conoscenza delle classi che le implementano. Questo è ciò che garantisce l’indipendenza dei livelli l’uno dall’altro: modificare l’implementazione del livello [DAO] non ha alcun impatto sul livello [business] fintanto che la definizione dell’interfaccia del livello [DAO] rimane invariata. Lo stesso vale tra i livelli [interfaccia utente] e [business].

L'architettura MVC (Model–View–Controller) viene implementata nel livello [interfaccia utente] quando si tratta di un'interfaccia web:

L'elaborazione di una richiesta del client segue questi passaggi:

1. Il client invia una richiesta al controller. Il controller gestisce tutte le richieste del client. È il punto di ingresso dell'applicazione. È la C in MVC.
2. Il controller C elabora questa richiesta. Per farlo, potrebbe aver bisogno dell’assistenza del livello business. Una volta elaborata la richiesta del cliente, può generare varie risposte. Un classico esempio è:
   • una pagina di errore se la richiesta non è stata elaborata correttamente
   • una pagina di conferma in caso contrario
3. Il controller sceglie la risposta (= vista) da inviare al client. La scelta della risposta da inviare al client comporta diversi passaggi:
   • selezionare l'oggetto che genererà la risposta. Questo è chiamato vista V, la V in MVC. Questa scelta dipende generalmente dal risultato dell'esecuzione dell'azione richiesta dall'utente.
   • fornirle i dati necessari per generare questa risposta. Infatti, questa risposta contiene molto spesso informazioni calcolate dal controller. Queste informazioni costituiscono ciò che viene chiamato il modello M della vista, la M in MVC.
   • Il passaggio 3 consiste quindi nel selezionare una vista (V) e costruire il modello (M) necessario per essa.
4. Il controller C ordina alla vista selezionata di visualizzarsi. Ciò comporta solitamente l'esecuzione di un metodo specifico della vista V responsabile della generazione della risposta al client. In questo documento, ci riferiremo sia all'oggetto che genera la risposta al client sia alla risposta stessa come vista. La letteratura MVC non è esplicita su questo punto. Se fosse la risposta a essere chiamata vista, potremmo chiamare l'oggetto che genera questa risposta generatore di vista.
5. Il generatore di vista V utilizza il modello M preparato dal controller C per inizializzare le parti dinamiche della risposta che deve inviare al client.
6. La risposta viene inviata al cliente. La sua forma esatta dipende dal generatore di vista. Può essere un flusso HTML, un PDF, un file Excel, ecc.

La metodologia di sviluppo web MVC non richiede necessariamente strumenti esterni. Pertanto, un'applicazione web Java con un'architettura MVC può essere sviluppata utilizzando un semplice JDK e librerie di sviluppo web di base. Un metodo adatto per applicazioni semplici è il seguente:

• Il controller è gestito da un singolo servlet. Questo è il C in MVC.
• Tutte le richieste del client contengono un attributo "action", ad esempio (http://.../appli?action=liste).
• A seconda del valore dell'attributo action, il servlet esegue un metodo interno di tipo [doAction(...)].
• Il metodo [doAction] esegue l'azione richiesta dall'utente. A tal fine, utilizza il livello [business] se necessario.
• A seconda del risultato dell'esecuzione, il metodo [doAction] decide quale pagina JSP visualizzare. Questa è la View (V) nel modello MVC.
• La pagina JSP contiene elementi dinamici che devono essere forniti dal servlet. Il metodo [doAction] fornirà questi elementi. Questo è il modello di vista, la M in MVC. Questo modello viene spesso inserito nel contesto della richiesta (request.setAttribute("key", "value"), o, meno frequentemente, nel contesto della sessione o dell'applicazione. Una pagina JSP ha accesso a questi tre contesti.
• Il metodo [doAction] visualizza la vista passando il flusso di esecuzione alla pagina JSP selezionata. A tal fine, utilizza un'istruzione del tipo [getServletContext() .getRequestDispatcher("pagina JSP").forward(request, response)].

Questo modello di progettazione MVC è chiamato modello "Front Controller" o modello a controller singolo. Un unico servlet gestisce tutte le richieste provenienti da tutti gli utenti.

Torniamo all'architettura dell'applicazione web precedente:

Questa architettura corrisponde alla seguente architettura a più livelli:

In realtà c'è un solo livello: il livello dell'interfaccia web. In linea generale, un'applicazione web MVC basata su servlet e pagine JSP avrà la seguente architettura:

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] 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 è 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 emersi strumenti, spesso chiamati "framework", per fornire agli sviluppatori queste funzionalità. Il più antico e probabilmente il più noto di questi è Struts (http://struts.apache.org/). Jakarta Struts è un progetto della Apache Software Foundation (www.apache.org). Questo framework è descritto in (http://tahe.developpez.com/java/struts/).

Il framework Spring (http://www.springframework.org/), apparso più di recente, offre funzionalità simili a quelle di Struts. Il suo utilizzo è stato descritto in diversi articoli (http://tahe.developpez.com/java/springmvc-part1/).

Presentiamo ora un esempio di architettura MVC basata su servlet e pagine JSP.