"Se ci sono due o più modi di fare una cosa,
e uno di questi modi può condurre a una catastrofe,
allora qualcuno la farà in quel modo.

(Edward Murphy)

Il primo pattern: MVC

Mer, 01/01/2014 - 19:01 -- arturu

Il primo problema che dovremo affrontare è la struttura della nostra applicazione, qui ci viene incontro l'ormai strafamoso MVC. Questa organizzazione ci permette di tenere separate le diverse parti del software in modo che ognuna faccia bene soltanto una cosa. Ricordiamo che il nostro problema è: realizzare una struttura software che riceve delle richieste, le analizza e ne restituisce il risultato. Quindi abbiamo bisogno di tre macro-elementi:

  • un elemento che riceve delle richieste (controller);
  • un elemento che analizza e produca dei risultati (model);
  • un elemento che visualizza i risultati (view).

Immagine MVC 1

L'immagine sopra è semplice da capire, abbiamo un utente che invia una richiesta che viene presa in carico dal Controller, il Controller la smista verso Model che la elabora, successivamente viene inviata a View per la visualizzazione. Ragionando su queste macro aree possiamo notare che abbiamo bisogno di ulteriori componenti, come: la gestione degli errori (Exception), la gestione delle richieste (gestione di GET e POST), un modulo per gestire la sicurezza dei dati che arrivano dall'esterno (Security), smistare le varie richieste (Routing), la gestione delle risorse (Resource), la gestione dei permessi (ACL), la logica applicativa (Logic), la gestione di un database (ORM e DB), un gestore grafico (Template Engine), un tema grafico (Theme). La cosa migliore da fare è suddividere le macro aree in componenti più piccoli, in modo d'avere la seguente situazione.

Immagine MVC 2

Nel corso del libro andremo a vedere che ogni singola parte sarà ancora frammentata in parti più piccole, come da linee guida, dobbiamo cercare di costruire moduli software che siano il più possibile: facili da mantenere, facili da capire da parte di un'altra persona, facili da riutilizzare.

Bene, mi sa che è meglio che iniziamo a scrivere qualche linea di codice, sento che ormai ti sei scocciato di leggere soltanto. Prima di iniziare a scrivere ti chiedo soltanto altri cinque minuti di tempo, leggi l'appendice in cui si parla dell'editor e del software di versionamento del codice, sono di vitale importanza.

Una prima bozza

Come prima cosa dobbiamo costruirci una struttura di cartelle. Nella root andiamo ad inserire index.php, .htaccess, una cartella per i moduli (che chiameremo "app"), una cartella per i file pubblici, una per i file temporanei. Tratteremo ogni singola parte/modulo del Framework come una piccola applicazione. Dentro la cartella "app" scriviamo un file "Autoloader.php" e "Config.php" che ci serviranno rispettamente per caricare automaticamente le classi e per memorizzare alcuni parametri di configurazione del Framework stesso. Ricordiamoci sempre che ogni file php che scriviamo deve iniziare con il tag di apertura dello script "<?php" senza spazi vuoti prima di esso, e che non dobbiamo chiudere il tag alla fine file, questo serve per non produrre output involontario. Abbiamo questa situazione:

/index.php

Vedi Codice Su GitHub

/.htaccess

Vedi Codice Su GitHub

/app/Autoloader.php

Vedi Codice Su GitHub

Attualemente l'autoload funziona caricando le classi nel formato "cartella_classe" oppure "cartella_cartella_classe" oppure "classe", dipende dalla posizione dove si trova il file, potremmo anche usare i namespaces, successivamente lo faremo, per ora a livello didattico facciamo in questo modo, affrontiamo un argomento per volta. Un esempio del funzionamento:


<?php
// dichiarazione di una classe dentro la cartella /app
class NomeClasse { ... }

// uso 
$obj = new NomeClasse;

// dichiarazione di una classe dentro una cartella /app/cartella
class Cartella_NomeClasse { ... }

// uso
$obj = new Cartella_NomeClasse;

// dichiarazione di una classe dentro una cartella /app/cartella/cartella
class Cartella_Cartella_NomeClasse { ... }

// uso
$obj = new Cartella_Cartella_NomeClasse;

// eccetera

 

Questo ci torna utile in quanto riusciamo ad essere organizzati e riusciamo a tenere separate le classi di ogni singola app (gestione utenti, rubrica, core, moduli ecc). Capire questo meccanismo ci aiuterà perché tra qualche capitolo useremo i Namespaces che funzionano più o meno allo stesso modo.

 

/app/.htaccess - /tmp/.htaccess

Vedi Codice Su GitHub

Fatta questa prima parte possiamo passare al prossimo passo, ci serve uno strumento per memorizzare le impostazioni della piattaforma.