Share
Model-View-Controller (MVC) è probabilmente uno degli schemi più citati nel mondo della programmazione web negli ultimi anni. Chiunque stia lavorando su qualcosa che riguarda lo sviluppo di applicazioni web avrà sentito o letto l'acronimo centinaia di volte. Oggi chiariremo cosa significa MVC e perché è diventato così popolare.
MVC non è un modello di progettazione, è un modello architettonico che descrive un modo per strutturare la nostra applicazione e le responsabilità e le interazioni per ogni parte in quella struttura.
Fu descritto per la prima volta nel 1979 e, ovviamente, il contesto era un po 'diverso. Il concetto di applicazione web non esisteva. Tim Berners Lee ha gettato i semi del World Wide Web nei primi anni Novanta e ha cambiato il mondo per sempre. Lo schema che usiamo oggi per lo sviluppo web è un adattamento del modello originale.
La popolarizzazione selvaggia di questa struttura per le applicazioni Web è dovuta alla sua inclusione in due framework di sviluppo che sono diventati immensamente popolari: Struts e Ruby on Rails. Questi due ambienti hanno segnato la strada per le centinaia di framework creati in seguito.
L'idea alla base del modello architettonico Model-View-Controller è semplice: dobbiamo avere le seguenti responsabilità chiaramente separate nella nostra applicazione:
L'applicazione è divisa in questi tre componenti principali, ciascuno responsabile di diversi compiti. Vediamo una spiegazione dettagliata e un esempio.
Il controllore gestisce le richieste degli utenti (ricevute come richieste HTTP GET o POST quando l'utente fa clic sugli elementi della GUI per eseguire azioni). La sua funzione principale consiste nel chiamare e coordinare le risorse / gli oggetti necessari per eseguire l'azione dell'utente. Di solito il controller chiama il modello appropriato per l'attività e quindi seleziona la vista corretta.
Il Modello sono i dati e le regole applicabili a quei dati, che rappresentano i concetti che l'applicazione gestisce. In qualsiasi sistema software, tutto è modellato come dati che gestiamo in un certo modo. Che cos'è un utente, un messaggio o un libro per un'applicazione? Solo i dati che devono essere gestiti secondo regole specifiche (la data non può essere in futuro, l'e-mail deve avere un formato specifico, il nome non può essere più lungo di x caratteri, ecc.).
Il modello fornisce al controller una rappresentazione dei dati di qualsiasi cosa l'utente abbia richiesto (un messaggio, un elenco di libri, un album fotografico, ecc.). Questo modello di dati sarà lo stesso indipendentemente da come potremmo presentarlo all'utente, ecco perché possiamo scegliere qualsiasi vista disponibile per renderla.
Il modello contiene la parte più importante della nostra logica applicativa, la logica che si applica al problema con cui abbiamo a che fare (un forum, un negozio, una banca, ecc.). Il controller contiene una logica interna più organizzativa per l'applicazione stessa (più come le pulizie).
Il vista fornisce diversi modi per presentare i dati ricevuti dal modello. Possono essere modelli in cui tali dati sono riempiti. Possono esserci diverse visualizzazioni e il controllore deve decidere quale utilizzare.
Un'applicazione Web di solito è composta da un insieme di controller, modelli e viste. Il controller può essere strutturato come un controller principale che riceve tutte le richieste e chiama specifici controller che gestiscono le azioni per ciascun caso.
Supponiamo che stiamo sviluppando un negozio di libri online. L'utente può eseguire azioni quali: visualizzare libri, registrare, acquistare, aggiungere articoli all'ordine corrente, creare o eliminare libri (se è un amministratore, ecc.). Vediamo cosa succede quando l'utente fa clic sul fantasia categoria per visualizzare i titoli che abbiamo a disposizione.
Avremo un controller particolare per gestire tutte le azioni relative ai libri (visualizzare, modificare, creare, ecc.). Chiamiamolo books_controller.php per questo esempio. Avremo anche un modello, ad esempio book_model.php, che gestisce i dati e la logica relativi agli articoli nel negozio. Infine avremo una serie di viste da presentare, ad esempio, un elenco di libri, una pagina per modificare libri, ecc.
La seguente figura mostra come viene gestita la richiesta dell'utente di visualizzare l'elenco di libri fantasy:
Il controller (books_controller.php) riceve la richiesta utente [1] come richiesta HTTP GET o POST (possiamo anche avere un controller centrale, ad esempio index.php che lo riceve e poi chiama books_controller.php).
Il controller esamina la richiesta e i parametri e chiama il modello (book_model.php) chiede lui a restituire la lista dei libri fantasy disponibili [2].
Il modello è responsabile per ottenere tali informazioni dal database (o dovunque sia memorizzato) [3], applicare filtri o logica, se necessario, e restituire i dati che rappresentano l'elenco dei libri [4].
Il controller utilizzerà la vista appropriata [5] per presentare questi dati all'utente [6-7]. Se la richiesta proviene da un telefono cellulare, verrà utilizzata una vista per i telefoni cellulari, se l'utente ha selezionato un particolare skin, verrà selezionata la vista corrispondente e così via.
Il vantaggio più ovvio che otteniamo utilizzando MVC è una chiara separazione tra presentazione (l'interfaccia con l'utente) e logica dell'applicazione.
Il supporto per diversi tipi di utenti che utilizzano diversi tipi di dispositivi è un problema comune in questi giorni. L'interfaccia presentata deve essere diversa se la richiesta proviene da un computer desktop o da un telefono cellulare. Il modello restituisce esattamente gli stessi dati, l'unica differenza è che il controller sceglierà una vista diversa per renderli (possiamo pensare a un modello diverso).
Oltre a isolare la vista dalla logica aziendale, la separazione M-V-C riduce la complessità durante la progettazione di applicazioni di grandi dimensioni. Il codice è molto più strutturato e quindi più semplice da mantenere, testare e riutilizzare.
Quando si utilizza un framework, la struttura di base per MVC è già pronta ed è sufficiente estendere tale struttura, collocando i file nella directory appropriata, per conformarsi al modello Model-View-Controller. Inoltre ottieni molte funzionalità già scritte e testate a fondo.
Prendete cakePHP come esempio di framework MVC. Una volta installato, vedrai tre directory principali:
Il App la cartella è dove metti i tuoi file. È il tuo posto dove sviluppare la tua parte dell'applicazione.
Il torta cartella è dove cakePHP ha i suoi file e dove hanno sviluppato la loro parte (funzionalità main framework).
Il fornitori la cartella è per le librerie PHP di terze parti, se necessario.
Il tuo posto di lavoro (directory app) ha la seguente struttura:
Ora devi mettere i controller in controllori directory, i tuoi modelli in Modelli directory e le tue opinioni in ... il visualizzazioni elenco!
Una volta che ti abitui al tuo framework, sarai in grado di sapere dove cercare quasi ogni pezzo di codice che devi modificare o creare. Questa organizzazione da sola rende la manutenzione molto più semplice.
Poiché questo tutorial non ha lo scopo di mostrare come creare un'applicazione utilizzando cakePHP, lo useremo solo per mostrare il codice di esempio per il modello, la vista e i componenti del controller e commentare i vantaggi dell'utilizzo di un framework MVC. Il codice è semplificato e non adatto per applicazioni reali.
Ricorda che avevamo un negozio di libri e un utente curioso che vuole vedere l'elenco completo dei libri nel fantasia categoria. Abbiamo detto che il responsabile sarà colui che riceve la richiesta e coordinerà le azioni necessarie.
Quindi, quando l'utente fa clic, il browser richiederà questo URL:
www.ourstore.com/books/list/fantasy
A CakePHP piace formattare gli URL nel formato / controller / azione / param1 / param2, dove azione è la funzione da chiamare all'interno del controller. Nel vecchio formato di url classico sarebbe:
www.ourstore.com/books_controller.php?action=list&category=fantasy
Con l'aiuto del framework cakePHP, il nostro controller sarà simile a questo:
Accentsconagua
set ('books', $ this-> Book-> findAllByCategory ($ category)); function add () ... function delete () ... ...?> Semplice, non è vero? Questo controller verrà salvato come books_controller.php e inserito in / app / controller. Contiene la funzione elenco, per eseguire l'azione nel nostro esempio, ma anche altre funzioni per eseguire altre azioni relative ai libri (aggiungere un nuovo libro, eliminare un nuovo libro, ecc.).
Il framework fornisce molte cose per noi e solo una riga è necessaria per elencare i libri. Abbiamo classi base con il comportamento del controller di base già definito, quindi ereditiamo da esse (AppController che eredita dal controller).
Tutto ciò che deve fare nella lista è chiamare il modello per ottenere i dati e quindi scegliere una vista per presentarla all'utente. Spieghiamo come è fatto.
this-> Prenota è il nostro modello e questa parte:
$ This-> Book-> findAllByCategory ($ categoria)
sta dicendo al modello di restituire l'elenco dei libri nella categoria selezionata (vedremo il modello più tardi).
Il impostato metodo nella linea:
$ this-> set ('books', $ this-> Book-> findAllByCategory ($ category)); È il modo controller per passare i dati alla vista. Imposta il libri variabile ai dati restituiti dal modello e li rende accessibili alla vista.
Ora dobbiamo solo rendere la vista, ma questo sarà fatto automaticamente da cakePHP se vogliamo la vista predefinita. Se abbiamo bisogno di altre viste, dobbiamo chiamarlo esplicitamente usando il rendere metodo.
Il modello è ancora più semplice:
Perché vuoto? Perché eredita da una classe base che fornisce le funzionalità necessarie e abbiamo seguito le convenzioni sui nomi di CakePHP per consentire al framework di svolgere automaticamente altre attività. Ad esempio, cakePHP sa, in base ai nomi, che questo modello è utilizzato in BooksController e che accederà a una tabella di database chiamata libri.
Con questa dichiarazione abbiamo solo un modello di libro in grado di leggere, cancellare o salvare dati dal database
Il codice verrà salvato come book.php e inserito in / app / modelli.
Tutto quello che dobbiamo fare ora è creare una vista (almeno una) per l'azione della lista. La vista avrà il codice HTML e poche (quante poche possibili) linee PHP per scorrere l'array di libri fornito dal modello.
| Titolo | Autore | Prezzo |
|---|---|---|
Come possiamo vedere, la vista non produce una pagina completa, solo un frammento HTML (una tabella in questo caso). Questo perché CakePHP fornisce un altro modo per definire il layout della pagina e le viste vengono inserite in quel layout. Il framework ci fornisce anche alcuni oggetti helper per semplificare il compito comune durante la creazione di questi estratti HTML (inserire moduli, collegamenti, Ajax o JavaScript).
Facciamo questa la vista di default salvandola come list.ctp (la lista è il nome dell'azione e ctp significa template della torta) e la posiziona in / app / views / books (all'interno dei libri perché sono viste per le azioni del controller dei libri).
E questo completa le tre componenti con l'aiuto del framework CakePHP!
Abbiamo appreso quello che è probabilmente il modello architettonico più comunemente usato oggi. Dobbiamo essere consapevoli però che quando parliamo di schemi nel mondo della programmazione, stiamo parlando di frame flessibili, da adattare al particolare problema in questione. Troveremo implementazioni che introducono variazioni sulla struttura che abbiamo visto, ma l'importante è che, alla fine, il modello ci aiuti a ottenere una chiara divisione tra responsabilità e migliore manutenibilità, riutilizzo del codice e test.
Abbiamo anche visto i vantaggi dell'utilizzo di un framework MVC che ci fornisce uno scheletro MVC di base e molte funzionalità, migliorando la nostra produttività e semplificando il processo di sviluppo. Grazie per aver letto!
