6
Introduzione
L'architettura di un software è fondamentale sia per la riuscita di un progetto entro i termini
stabiliti sia per rendere il progetto stesso mantenibile ed aggiornabile nel tempo. Da
quando si è sviluppato il concetto di Web 2.0 l'attenzione si è spesso focalizzata sulla
parte client delle applicazioni e sul loro look and feel, lasciando in disparte la comunque
fondamentale parte server.
Dal punto di vista dello scripting web (o della programmazione) sono andati sempre di più
ad affermarsi i framework MVC [1].
Ruby on Rails è stato sicuramente quello che per primo ha destato l'interesse di un gran
numero di sviluppatori che hanno visto nel pattern MVC e nei framework RAD (Rapid
Application Development) una sorta di rinnovata (perché parlare di nuova sarebbe
sicuramente eccessivo) e ritrovata concezione dello sviluppo web.
Il continuo crescere dell'interesse ha causato la nascita di decine di progetti simili
sviluppati in altri linguaggi, sia seguendo lo stesso concetto di base che adattandolo alle
esigenze specifiche di alcune situazioni; la base MVC è però rimasta sempre, dato che la
separazione tra i concetti di dati, aspetto e comportamento semplifica notevolmente i
processi di sviluppo e i futuri interventi sul codice.
Cosa si intende per framework MVC?
Un framework MVC è un prodotto (ovviamente software) che sfrutta come approccio di
lavoro ai problemi il pattern MVC, ovvero un approccio che scompone gli elementi di un
applicativo in tre categorie, in modo da poter gestire ogni categoria in maniera autonoma,
con appropriati strumenti messi a disposizione dal framework stesso.
Queste tre catogrie sono: Model, View e Controller.
7
Ognuna di queste tra categorie (che chiameremo anche livelli), come già accennato, si
occupa delle gestione di un particolare aspetto dell’applicativo, utlizzando strumenti potenti
e specifici per ottimizzare l’implementazione di ogni singola parte.
Il livello Model è il livello deputato alla gestione dei dati che devono essere manipolati
dall’applicativo. Il suo compito è quello di riuscire ad astrarre la strutturazione dei dati
all’interno del supporto in cui sono salvati e mettere a disposizione dell’utente una serie di
strumenti e di strategie per interrogarli e manipolarli in maniera semplice e precisa, senza
dover necessariamente ricorrere al linguaggio di interrogazione tipico della struttura dati in
cui essi sono salvati.
Il livello View è anche detto livello di Visualizzazione. Ad esso è deputato l’importante
compito di fornire all’utente un’adeguata visualizzazione dei dati e di tutte le strutture che
circolano nel sistema dell’applicazione.
In linea generale, il suo compito è quello di costruire delle pagine (generalmente scritte in
linguaggio HTML nell’ambiente WEB) che abbiano una struttura predefinita, ma che
possano riempirsi dinamicamente di contenuti in funzione dei risultati che l’utente vorrebbe
ottenere.
Più precisamente, le pagine devono essere scritte in modo da poter fornire una
visualizzazione generale e fissa per tutte le parti che non mutano nel tempo, mentre deve
fornire delle “porzioni” di queste pagine che non siano riempite automaticamente dal
programmatore, ma che vadano a popolarsi di contenuti ogni volta che la situazione lo
richiede.
Infine abbiamo il livello Controller. Senza nulla togliere ai due livelli precedenti, il livello
Controller è sicuramente da cosiderare il più importante nel framework MVC. Esso infatti
ricopre il ruolo di cervello di tutta l’applicazione.
Nel livello di Controller sono raccolti tutti gli strumenti che permettono di catturare le
richieste effettuate dall’utente e di processarle in modo da fornire un risultato finale.
Esso si occupa di intercettare le richieste dell’utente, di selezionare i componenti in grado
di processare tali richieste, di reperire i dati di competenza (sfruttando gli strumenti del
8
Model) e di richiamare la corretta visualizzazione per i dati (sfruttando anche in questo
caso gli strumento del livello View).
Suddividere queste categorie dell’applicazione in livelli specifici, offre notevoli vantaggi in
fatto di manutenibilità dell’intera applicazione: potersi concentrare su una singola parte
più piccola e semplice è molto più facile che dover ricercare la stessa parte all’interno di
un mondo più vasto e articolato e poi doverla manipolare, senza tenere conto che questa
parte potrebbe intrecciarsi con le altre in qualsiasi momento, rendendo il compito ancora
più complicato.
Per questo e altri motivi è stato scelto di svillupare l’applicativo ELEGEN con uno
strumento potente ed articolato come un framework MVC.
Perché “un” framework e non “il” framework?
Molti lettori probabilmente si staranno domandando come mai il titolo della tesi sia
“Impiego di un framework MVC per la realizzazione di un applicativo gestionale” piuttosto
che “Impiego de il framework MVC per la realizzazione di un applicativo gestionale”.
La motivazione di questa scelta è piuttosto semplice: non esiste un solo framework MVC.
Anzitutto dobbiamo stabilire dove sta la differenza tra paradigma MVC e framework
MVC.
Il paradigma MVC è da vedere come una filosofia, una metodologia di approccio ad un
problema. Il paradigma comprende l’idea di suddividere il problema da sviluppare nelle tre
categorie fondamentali che lo compongono: il Model, il View e il Controller.
Il framework MVC invece, è l’insieme di tutti gli strumenti di lavoro messi a disposizione
da un soggetto (che può essere un insieme di programmatori, un’azienda produttrice di
software, ecc..) per permettere di sviluppare un problema tramite l’approccio MVC. Quindi,
9
per esempio, mettere a disposizione un linguaggio gi programmazione con cui il
framework lavora, fornire delle classi che implementino determinate funzioni, eccetera.
Quindi di framework MVC ne possono esistere diversi, magari molto differenti tra loro
nell’implementazione e anche nel linguaggio con cui sono sviluppati, oltre che negli IDE da
usare per utilizzarli.
E’ invece la filosofia (o paradigma) MVC ad essere unica. Unica nella sua idea di
suddividere il problema nelle tre aree specifiche e di delegare opportuni componenti alla
relativa gestione.
Il framework MVC utilizzato
Fatta la doverosa premessa sulla non-unicità dei framework MVC, introduciamo ora il
nostro framework MVC, ovvero quello utilizzato per lo sviluppo dell’applicativo ELEGEN.
Il framework è stato sviluppato con l’utilizzo di linguaggio PHP5, più diverse funzionalità
basate sull’utilizzo di Javascript ed Ajax.
E’ stato scelto di utilizzare PHP5 in quanto è un linguaggio che ha subito numerosi
miglioramenti dalla sua versione precedente PHP4, ed inoltre mette a disposizione degli
strumenti fondamentali per l’implementazione dei tre livelli del framework: un potente
sistema di classi.
Senza l’ausilio di questi nuovi strumenti non si sarebbe potuto sviluppare il framework, in
quanto solo l’utilizzo delle classi permette la giusta suddivisione dei componenti dei tre
livelli e la giusta dose di interazione fra le relative parti.
Il livello Model
Il livello Model è il livello che si occupa della manipolazione dei dati. Essi sono mantenuti
all’interno di un database MySql.
Per evitare la continua scrittura di interrogazioni SQL al database, il livello Model sfrutta un
componente esterno, il cui scopo è quello di mappare le tabelle contenute nel database e
10
di riprodurle sottoforma di classi più facilmente manipolabili: questo componente prende il
nome di ORM (Object-relational mapping) e nello specifico è stato scelto OutletORM.
Grazie all’ORM il programmatore può dimenticarsi la scrittura di noiose (e spesso anche
articolate) query SQL, delegando il compito ad uno strumento automatizzato, con il solo
ausilio di poche e semplici istruzioni.
Il livello Model fornisce inoltre una classe particolare denominata BaseModel. Al suo
interno sono contenuti tutti i metodi ricorrenti che possono essere richiamati durante
l’esecuzione dell’applicazione per soddisfare svariate esigenze.
Ogni tabella del database è mappata all’interno del livello di Model da una classe
specifica: ogni classe contiene campi e proprietà della tabella che sta mappando.
Tutte le classi del Model inoltre, estendono per ereditarietà la classe BaseModel, in modo
che ognuna possa sfruttare i metodi in essa dichiarati senza doverli riscrivere ogni volta.
Il livello View
Il livello View è il livello di visualizzazione delle videate e dei dati.
Nel livello View sono salvati numerosi file scritti (quasi) interamente in linguaggio HTML.
Questi file prendono il nome di template e sono contraddistinti dall’estensione .tpl.
In tutti questi file sono contenute semplici istruzioni HTML che, una volta processate,
forniranno al client la grafica della pagina da visualizzare.
In alcune di queste pagine sono però inseriti dei componenti particolari denominati
marcatori. Sono distinguibili in quanto il loro nome è preceduto dal simbolto di dollaro
($nome_marcatore).
La presenza di un marcatore sta a significare che in quel punto del template dovrà essere
“iniettata” una nuova stringa HTML (o addiritura un nuovo template) generata durante
l’esecuzione dell’applicazione.
E’ in questo modo che il framework gestisce i contenuti dinamici delle pagine: ogni
marcatore simboleggia un punto della pagina che di volta in volta avrà un contenuto
mutevole.
11
E’ stato creato un template generico (chiamato GestioneElegen.tpl) detto MacroTemplate
che contiene tutti gli elementi che non muteranno mai durante l’esecuzione
dell’applicazione (come la struttura generale della pagina, il menù di navigazione,
l’intestazione della pagina, ecc…).
Per ogni altra pagina è stato creato un template apposito (chiamato genericamente
SubTemplate) che, una volta invocato, viene processato e posizionato all’interno del
punto corretto del MacroTemplate GestioneElgen.tpl, individuato dal marcatore $Contents.
Nel livello View, sono inoltre contenute le immagini che vanno a comporre la grafica della
pagina, i file contenenti i metodi javascript invocati all’interno delle pagine e una serie di
altri componenti denominati Widget.
I Widget sono delle classi PHP che possono essere istanziate come oggetti all’interno
delle pagine dell’applicazione. Essi forniscono all’utente la possibilità di creare
automaticamente dei componenti di uso comune come i menù a tendina, i bottoni, i campi
testo e le tabelle di dati.
La potenza dei Widget risiede nel fatto che essi possono essere alimentati con una
sorgente dati esterna e automaticamente il componente comparirà a video popolato senza
alcuno sforzo ulteriore da parte dell’utente.
Il livello Controller
In ultimo abbiamo il livello Controller, che funziona da cervello di tutta l’applicazione,
rispondendo alle richieste dell’utente, interpellando i Model corretti e i template adeguati.
Come il livello Model, anche nel livello Controller tutti i componenti sono rappresentati da
classi PHP.
Esiste una classe particolare denominata BaseController che contiene tutti i metodi e le
proprietà che sono ricorrenti in tutti gli altri Controller. In particolar modo sono definiti i
metodi per consentire l’individuazione dei template corretti e l’appropriato riempimento dei
marcatori con i contenuti adeguati.
12
Ogni Controller implementa un determinato gruppo di funzioni, che generalmente vengono
tutte svolte all’interno della stessa pagina visualizzata. Tutti i Controller estendono per
ereditarietà la classe BaseController, in modo che i metodi in essa contenuti non debbano
essere ridichiarati ogni volta.
Il costruttore di ogni Controller è il fulcro del Controller stesso. In esso vengono
innanzitutto individuati i template da caricare e, con una serie di istruzioni, vengno
valorizzati tutti i marcatori contenuti nel MacroTemplate e negli eventuali SubTemplate
caricati.
Oltre al costruttore, nel Controller sono anche dichiarati tutti i metodi e le proprietà
necessari per eseguire tutte le funzionalità specifiche ad esso richieste.
Quando l’utente invoca l’esecuzione di una pagina, lo fa passando tramite URL un
parametro chiamato action opportunamente valorizzato.
Spetta al controllerBinding (un particolare file salvato in radice del framework) catturare il
valore di action e individuare quale sia il Controller da invocare per soddisfare le
esigenze correlate a tale richiesta.
Pregi, difetti e possibili migliorie per il framework
Come già detto, il prodotto framework è stato scelto per la sua potenza nell’affrontare certi
tipi di problematiche, specialmente per la sua attitudine a rendere l’applicativo software
nettamente più mantenibile rispetto a svilupparlo con altri strumenti più tradizionali.
Ogni livello del framework MVC nasconde in se una quantità importante di vantaggi che lo
sviluppatore si trova a poter sfruttare nello sviluppo dell’applicativo.
Il livello Model rende notevolmente più semplice la manipolazione dei dati grazie
all’impiego dell’ORM, al quale viene totalmente delegato il compito di colloquiare con il
database, sollevando l’utente dall’oneroso compito di saper “parlare” il dialetto compreso
da uno specifico database. E’ stato scelto di utilizzare una piattaforma MySql come
13
database, ma nulla impedisce di utilizzare piattaforme diverse in quanto l’ORM è
configurabile per comprendere diversi tipi di dialetti.
Il livello View rende notevolmente più facile gestire le singole pagine. Infatti, tolto il
MacroTemplate che contiene la grafica generale di tutte le pagine (ed è quindi composto
da una quantità notevole di istruzioni HTML), tutti gli altri SubTemplate sono molto più
semplici nella struttura, a volta addiritura composti da pochi tag HTML e un marcatore.
Quindi anche il fatto di modificarli o correggerli è molto più semplice, in quanto abbiamo a
che fare con poche istruzioni HTML piuttosto che con una lunga serie di stringhe.
Inoltre teniamo separato costantemente il codice PHP dal codice HTML, il che non è cosa
di poco conto.
Infine il livello Controller con la rigidità delle sue strutture, rende molto più ridotta la
possibilità da parte del programmatore di compiere errori in fase di creazione delle singole
pagine. Infatti le pagine del Controller necessitano di una certa sequenza di passi per
essere ben formattate, e quindi il programmatore si trova spesso nell’impossibilità di
compiere azioni che sarebbero considerate erronee.
L’avere a disposizione dei componenti prefatti come i Widget, riduce poi notevolmente i
tempi di scrittura del codice e più performanti le pagine stesse. Se una singola Widget
dovesse subire una modifica a livello strutturale, tutte le Widget dello stesso tipo create in
tutte le pagine sarebbero subito in grado di percepire la modifica e di applicarla
immediatamente.
Essendo però il framework un prodotto nuovo e giovane, non è esente da problemi e difetti
di varia natura.
Ad esempio, i metodi creati all’interno del livello Model non sono ancora in grado di
eseguire delle interrogazioni complesse sui dati, come ad esempio interrogazioni che
comprendono nella clausola di WHERE delle condizioni da testare in OR invece che in
AND, piuttosto che condizioni di LIKE.
Oppure l’ORM stesso che è in grado solamente di eseguire delle JOIN interne e non è
minimamente in grado di eseguire delle JOIN esterne.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
