4. Sviluppo MVC (Modello – Vista – Controller)

Un’applicazione web presenta spesso un’architettura a tre livelli:

il livello [dao] si occupa dell’accesso ai dati, il più delle volte dati persistenti all’interno di un SGBD. Ma possono essere anche dati provenienti da sensori, dalla rete, ...
il livello [metier] implementa gli algoritmi "di business" dell'applicazione. Questo livello è indipendente da qualsiasi forma di interfaccia con l'utente. Deve quindi essere utilizzabile sia con un'interfaccia da console, sia con un'interfaccia web, sia con un'interfaccia client ricca. Deve quindi poter essere testato al di fuori dell'interfaccia web e, in particolare, con un'interfaccia da console. È generalmente il livello più stabile dell'architettura. Non cambia se si modifica l'interfaccia utente o il modo di accedere ai dati necessari al funzionamento dell'applicazione.
il livello [interface utilisateur], che costituisce l’interfaccia (spesso grafica) che consente all’utente di gestire l’applicazione e di ricevere informazioni da essa.

La comunicazione avviene da sinistra a destra:

l’utente invia una richiesta al livello [interface utilisateur]
questa richiesta viene formattata dal livello [interface utilisateur] e trasmessa al livello [métier]
se, per elaborare questa richiesta, il livello [métier] necessita dei dati, li richiede al livello [dao]
ogni livello interpellato invia la propria risposta al livello precedente, fino alla risposta finale all’utente.

I livelli [métier] e [dao] vengono normalmente utilizzati tramite interfacce Java. Pertanto, il livello [métier] conosce del livello [dao] solo la sua o le sue interfacce e non conosce le classi che le implementano. È questo che garantisce l’indipendenza dei livelli tra loro: modificare l’implementazione del livello [dao] non ha alcuna incidenza sul livello [métier] fintanto che non si interviene sulla definizione dell’interfaccia del livello [dao]. Lo stesso vale per i livelli [interface utilisateur] e [métier].

L’architettura MVC (Modello – Vista – Controller) si colloca nel livello [interface utilisateur] quando quest’ultimo è un’interfaccia web:

L’elaborazione di una richiesta da parte di un cliente si svolge secondo le seguenti fasi:

il cliente invia una richiesta al controller. Quest’ultimo gestisce tutte le richieste dei clienti. Rappresenta il punto di ingresso dell’applicazione. È la «C» di MVC.
il controller C elabora questa richiesta. A tal fine, potrebbe aver bisogno dell’aiuto del livello di business. Una volta elaborata la richiesta del cliente, questa può generare diverse risposte. Un esempio classico è:
- una pagina di errore se la richiesta non è stata elaborata correttamente
- una pagina di conferma in caso contrario
il controller sceglie la risposta (= vista) da inviare al cliente. La scelta della risposta da inviare al cliente richiede diverse fasi:
- scegliere l’oggetto che genererà la risposta. È ciò che viene chiamato la vista V, la V di MVC. Questa scelta dipende in genere dal risultato dell’esecuzione dell’azione richiesta dall’utente.
- fornirle i dati necessari per generare tale risposta. Infatti, questa contiene molto spesso informazioni calcolate dal controller. Queste informazioni costituiscono ciò che viene chiamato il modello M della vista, la M di MVC.
- La fase 3 consiste quindi nella scelta di una vista V e nella costruzione del modello M necessario per essa.
Il controller C richiede alla vista scelta di visualizzarsi. Si tratta, nella maggior parte dei casi, di far eseguire un metodo specifico della vista V incaricato di generare la risposta al cliente. In questo documento, chiameremo «vista» sia l’oggetto che genera la risposta al cliente sia la risposta stessa. La documentazione MVC non è esplicita su questo punto. Se fosse la risposta a doversi chiamare vista, si potrebbe definire generatore di vista l’oggetto che genera tale risposta.
Il generatore di vista V utilizza il modello M preparato dal controller C per inizializzare le parti dinamiche della risposta che deve inviare al cliente.
La risposta viene inviata al client. La forma esatta di quest’ultima dipende dal generatore di vista. Può trattarsi di un flusso HTML, PDF, Excel, ...

La metodologia di sviluppo web MVC non richiede necessariamente strumenti esterni. È quindi possibile sviluppare un’applicazione web Java con un’architettura MVC utilizzando un semplice JDK e le librerie di base per lo sviluppo web. Un metodo utilizzabile per applicazioni semplici è il seguente:

il controllo è gestito da un unico servlet. Si tratta del C di 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 fa eseguire un metodo interno di tipo [doAction(...)].
Il metodo [doAction] esegue l’azione richiesta dall’utente. A tal fine, se necessario, utilizza il livello [métier].
A seconda del risultato dell’esecuzione, il metodo [doAction] decide quale pagina JSP visualizzare. Si tratta della vista V del modello MVC.
La pagina JSP contiene elementi dinamici che devono essere forniti dal servlet. Il metodo [doAction] fornirà tali elementi. Si tratta del modello della vista, la M di MVC. Questo modello viene solitamente inserito nel contesto della richiesta (request.setAttribute("chiave", "valore")), 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 trasmettendo il flusso di esecuzione alla pagina JSP selezionata. A tal fine, utilizza un’istruzione del tipo [getServletContext() .getRequestDispatcher(" pageJSP ").forward(request, response)].

Questo modello di architettura (Design Pattern) MVC è denominato modello “Front Controller” o modello a controller unico. Un unico servlet gestisce tutte le richieste di tutti gli utenti.

Torniamo all’architettura dell’applicazione web precedente:

Questa architettura corrisponde alla seguente architettura ntier:

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

Per applicazioni semplici, questa architettura è sufficiente. Quando si sono scritte diverse applicazioni di questo tipo, ci si accorge che i servlet di due applicazioni diverse:

utilizzano lo stesso meccanismo per determinare quale metodo [doAction] debba essere eseguito per elaborare l’azione richiesta dall’utente
differiscono infatti solo per il contenuto di questi 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é la servlet generica non sa in quale applicazione viene utilizzata
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. 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.