Introduzione al Model-View-Controller (MVC) Maurizio Cozzetto 9 Luglio 2009 Indice 1 Model-View-Controller 1 1.1 Definizione.................................................. 1 1.2 Soluzione................................................... 1 1.3 Schema di funzionamento.......................................... 2 1.4 Design Pattern................................................ 2 1.5 Framework.................................................. 2 2 Un caso di studio 3 2.1 Il problema.................................................. 3 2.2 Un approccio ingenuo........................................... 3 2.3 Presentazione e logica di business...................................... 3 2.4 La Vista.................................................... 4 2.5 Il Modello................................................... 4 2.6 Il Controllore................................................. 4 3 Il codice 6 1 Model-View-Controller 1 1.1 Definizione Model-View-Controller (MVC, talvolta tradotto in italiano Modello-Vista-Controllore) è il nome di un design pattern fondamentale nello sviluppo di interfacce grafiche di sistemi software object-oriented. Originariamente impiegato dal linguaggio Smalltalk, il pattern è stato esplicitamente o implicitamente sposato da numerose tecnologie moderne, come framework basati su Java (Swing, JSF e Structs) su Objective C o su.net. A causa della crescente diffusione di tecnologie basate su MVC nel contesto di framework o piattaforma middleware per applicazioni Web, l espressione framework MVC o sistema MVC sta entrando nell uso anche per indicare specificatamente questa categoria di sistemi (che comprende per esempio Struts, Spri ng e Tapestry). 1.2 Soluzione La soluzione viene interpretata a modo proprio dagli implementatori, ma in linea generale è questa: l applicazione deve separare i componenti software che implementano il modello delle funzionalità di business (Model), dai componenti che implementano la logica di presentazione (View) e la logica di controllo (Controller). 1 Questa parte è adattata da http://it.wikipedia.org/wiki/model-view-controller 1
Figura 1: Schema generico del MVC 1.3 Schema di funzionamento Model è il cuore dell applicazione. Definisce i dati e le operazioni che possono essere eseguiti su essi. Fornisce delle funzioni per l accesso e l aggiornamento. Può inoltre avere la responsabilità di notificare ai componenti della View eventuali aggiornamenti verificatisi in seguito a richieste del Controller, al fine di permettere alle View di presentare agli occhi degli utenti dati sempre aggiornati. View è l interfaccia grafica (GUI) con cui l utente interagisce. Il Controller ha la responsabilità di trasformare le interazioni dell utente della View in azioni eseguite dal Model. Ma il Controller non rappresenta un semplice ponte tra View e Model. Realizzando la mappatura tra input dell utente e processi eseguiti dal Model, il Controller implementa la logica di controllo dell applicazione. 1.4 Design Pattern Nell ingegneria del software, un design pattern può essere definito come una soluzione progettuale generale a un problema ricorrente. Esso non è una libreria o un componente di software riusabile, quanto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software. La differenza tra un algoritmo e un design pattern è che il primo risolve problemi computazionali, mentre il secondo è legato agli aspetti progettuali del software. 1.5 Framework Nella produzione del software, il framework è definito come una struttura di supporto dove un software può essere organizzato e progettato. Un framework include il programma di gestione, le librerie di codice, un linguaggio di scripting e altro materiale in grado di aiutare gli sviluppatori a unire tutti i vari materiali prodotti per fornire il software finale. Il framework è sviluppato con l intento di facilitare la produzione di software, permettendo ai programmatori di concentrarsi sulla qualità del codice e pensando meno a dettagli minori come il linking fra le varie risorse. 2
Figura 2: La pagina web che vogliamo realizzare 2 Un caso di studio 2.1 Il problema Vogliamo realizzare una pagina web che presenti in forma di scheda le informazioni relative ad alcuni personaggi dei fumetti pubblicati dalla casa editrice DC Comics, come quella rappresentata in figura 2. Le informazioni sui personaggi si trovano in un database MySQL (database supereroi, tabella dc supereroi, figure 4 e 5). Il file supereroi.sql provvede alla generazione del database e della tabella dei supereroi. 2.2 Un approccio ingenuo La prima cosa che sicuramente verrebbe in mente di fare subito è quella di riunire all interno di una singola pagina web, tutto il codice, sia HTML che Php, di gestione delle informazioni. Così facendo però la lettura e la manutenzione del codice nel corso del tempo sarebbe difficoltosa in quanto il codice php normalmente è immerso nei tag html. E chiaro che in questo caso, potremmo anche soprassedere dal momento che la pagina web è una sola ma possiamo facilmente immaginare cosa accadrebbe se il nostro applicativo fosse costituito da qualche centinaio di pagine: certamente avremmo dei forti mal di testa! 2.3 Presentazione e logica di business Un approccio più professionale consiste invece nel chiedere al grafico di preparare una pagina web (come quella della figura 3), cioè un template, che contenga dei segnaposto delle informazioni da rappresentare: i grafici non amano lavorare (salvo eccezioni) col codice php o con codice di qualsiasi altro tipo che non sia codice HTML. D altra parte, il programmatore non desidera che il grafico vada a toccare quelle parti di codice che gli sono costate sudore e fatica! Grafica e codice sono due mondi separati ma che in qualche modo devono convivere: di solito si dice che la grafica si colloca al livello della presentazione mentre il codice si colloca al livello della cosiddetta business logic. Sfruttiamo allora lo schema MVC per risolvere il problema. 3
Figura 3: Il template view.tpl come appare in Dreamweaver 2.4 La Vista Per realizzare il template (cioè la Vista, file view.tpl), useremo il package PEAR HTML Template IT. Un template consiste nella struttura grafica della pagina (realizzata ad esempio mediante fogli di stile) e in una serie di marcatori contenuti in blocchi logici denominati region. Tali campi saranno sostituiti con dei valori reali (quelli prelevati appunto dal database) con la fase di parsing. La logica di business sarà invece realizzata a parte mediante codice php. Particolari istruzioni consentiranno di realizzare la corrispondenza tra i segnaposto inseriti nel modello grafico e le variabili. Potremmo in alternativa usare un qualsiasi altro framework con le stesse funzionalità (ad esempio Smarty, www.smarty.net). Se usiamo XAMPP, il package HTML Template IT è già preinstallato per cui non dobbiamo fare nulla. 2.5 Il Modello Per realizzare il Modello, scriviamo alcune classi di supporto: la classe Costanti.php per le costanti di accesso al database MySQL, la classe SuperEroe.php che modellerà un personaggio e la classe Model.php che conterrà i metodi di accesso al database e che ci consentirà di prelevare le informazioni sui personaggi. La classe Model.php non conterrà in alcun modo istruzioni che fanno riferimento a codice HTML. Il controllo sugli errori è stato implementato alla maniera delle JavaServer Pages (JSP) centralizzando il codice in un unico punto e rilanciando le eccezioni verso la pagina gestioneerrori.php. 2.6 Il Controllore Il ruolo del Controller sarà svolto dalla pagina controller.php (è la pagina index.php rinominata). Il Controller provvederà a richiamare il codice del Model e sostituirà i segnaposto contenuti nella Vista con dei valori reali. 4
Figura 4: La struttura della tabella dc supereroi Figura 5: Alcuni dati di esempio 5
3 Il codice L applicativo (file MVCPhpApp2.zip) è composto dai seguenti file: view.tpl Costanti.php SuperEroe.php Model.php controller.php gestioneerrori.php supereroi.sql Iil codice è liberamente scaricabile dal sito o direttamente dal link precedente, assieme alle altre risorse come le immagini, il template ecc. Abbiamo preferito non includere il codice in questo documento per non appesantire troppo la trattazione dal momento che il codice è sufficientemente documentato. 6