Lecture: https://elearning.unimib.it/mod/kalvidres/view.php?id=1152364

Il Model-View-Controller (MVC) è un pattern architetturale molto diffuso nello sviluppo di sistemi software, in particolare nell’ambito della programmazione orientata agli oggetti e in applicazioni web, in grado di separare la logica di presentazione dei dati dalla logica di business. Partiamo analizzando il pattern architetturale:

Dove con le frecce piene si hanno le invocazioni di metodi e con quelle tratteggiate gli eventi. Analizzando meglio le tre componenti si ha che:

1. Model incapsula lo stato dell’applicazione, risponde alle query di stato, espone le funzionalità dell’applicazione e notifica la vista delle modifiche. In altri termini fornisce i metodi per accedere ai dati utili dell’applicazione. E’ implementato dalle classi che realizzano la logica applicativa, possiamo dire che sia il “backend”
2. View renderizza il modello, richiede l’aggiornamento dai modelli, invia le operazioni dell’utente al controller e gli permette di selezionare la vista. In altri termini visualizza i dati contenuti nel model e si occupa dell’interazione con utenti e agenti. Presenta lo stato del model all’utente, magari con una GUI
3. Controller definisce il comportamento dell’applicazione, mappa le azioni dell’utente ad update del Model, seleziona le viste per le risposte. In altri termini riceve i comandi dell’utente (in genere attraverso il View) e li attua modificando lo stato degli altri due componenti. Si ha un Controller per funzionalità. E’ un mediatore tra View e Model

La View raccoglie gli input dell’utente e li inoltra al Controller, che li mappa in operazioni sul Model, che viene modificato. A questo punto il Controller seleziona la nuova View da mostare all’utente, che a sua volta interagisce per avere i dati con il Model. Cambi del model sono notificati alla View per eventuali cambiamenti dei dati.

• Esempio: pagina HTML
• Esempio: pagina dinamica

[ripasso di concetti utili, da pp.84 a 88]

Controller Design

Dal punto di vista del Controller Design si hanno vari design pattern:

• Page Controller, che si occupa di controllare i parametri delle richieste (tipo una POST) e richiamare la business logic sulla base della richiesta, di selezionare la view successiva da mostrare e di preparare i dati per la presentazione. Si ha il seguente flusso di controllo:

  1. il controllo si sposta dal server Web al Page Controller
  2. il Page Controller estrae i parametri dalla richiesta
  3. il Page Controller utilizza alcuni oggetti di business
  4. il Page Controller decide la view successiva
  5. il Page Controller prepara i dati da mostrare nella view successiva
  6. il Page Controller porta il controllo (e i dati) alla view

  Dal punto di vista implementativo si possono usare soluzioni con poca logica di controllo (ASP, JSP, PHP, ecc…), con una forte logica di controllo (CGI script, serverlet, ecc…). Con questo pattern si implementa un controller per ciascuna “pagina”, avendo, per la scalabilità, la crescita finita del controller proporzionale al numero di “pagine” necessarie, producendo un numero comunque finito e gestibile di file di codice piccoli.

  

  Page controller, con una semplice implementazione con due controller (uno per la matematica e uno per le stringhe), implementati come serverlet. Si nota anche il collegamento diretto tra la view e il model.

• Front Controller che definisce un singolo componente che gestisce tutte le richieste, eseguendo le operazioni comuni a tutte le richieste (come autenticazione, questioni di sicurezza, tracciamento, ecc…) e poi esegue la specifica operazione che è stata richiesta, passando il parametro come parametro. Ogni comando è rappresentato da una classe, con un metodo che esegue il comando (ad esempio process), interagendo con la logica applicativa per svolgere quanto deve. Vediamo quindi l’UML associato:

  

  anche nel caso di un front controller si potrebbero avere più controller (ma solitamente se ne ha uno solo).

  Cresce la gerarchia di comandi e non l’handler, avendo quindi controllo sulla scalabilità. Nel dettaglio l’handler:

  • riceve la richiesta del server
  • esegue operazioni generali / comuni a tutti i comandi
  • decide l’operazione che deve essere eseguita e alloca l’istanza del comando
  • delega l’esecuzione al concrete command

  mentre il concrete command:

  • estrae i parametri dalla richiesta
  • invoca metodi implementati nella business logica
  • determina la vista successiva
  • dà il controllo al View

  Il front controller è più complesso del page controller. Inoltre evita la duplicazione del codice tra i vari Controller (avendo mediamente un solo front controller e avendo un entry point unico per tutte le richieste), permette una semplice configurazione del server avendo una sola serverlet, permette di gestire dinamicamente nuovi comandi e facilita l’estensione del Controller.

  

  Si hanno framework dove la gerarchia dei comandi è gestita diversamente.

• Intercepting Filter che è utile per gestire richieste e risposte prima che vengano servite. Viene spesso usato insieme al front controller per “decorare” richieste e risposte con funzioni aggiuntive, come autenticazione, logging, conversione dati, ecc…

  Si ha quindi il seguente UML:

  

  e il seguente comportamento:

  

  Dal punto di vista implementativo il web server fornisce Filter Manager e Filter chain, dovendo quindi implementare e dichiarare solo il filter (o più di uno)

• Application Controller usato in quanto all’aumentare della complessità del flusso, la gestione del flusso potrebbe essere concentrata in una classe. Solitamente viene usato dal page controller o dal front controller, secondo il seguente comportamento:

  

View Design