Evoluzione della programmazione sul web

Tutto ciò che è stato analizzato nei precedenti moduli del corso, è rivolto ad un approccio per lo più sequenziale della programmazione ovvero una serie predefinitità di operazioni e funzionalità nella strutturazione del software.

La crescita esponenziale del web e delle conseguenti applicazioni orientate ad un utilizzo massivo ed imponente, ha però messo in discussione l'approccio sequenziale, con l'esigenza di dover definire linee guida omogenee per lo sviluppo sul web.

La soluzione definita attualmente è dunque molto più strutturata e prevede specifiche buone norme da dover seguire per un processo omologato e condivisibile.

Evoluzione della programmazione sul web

In quest'analisi dei nuovi standard della programmazione sul web, occorrerà dunque mettere in discussione una buona parte di nozioni e approcci che erano ormai diventati standard per i moduli precedenti del corso, aprendosi ad una nuova mentalità più scalabile e razionale, seppur a prima vista molto complessa.

Nel nuovo percorso analizzeremo dunque i seguenti aspetti teorici e pratici:

  • Programmazione ad oggetti
  • Pattern MVC
  • Gestione degli accessi

Programmazione ad oggetti

Evoluzione dell'architettura di back-end

Programmazione ad oggetti

Anche nel PHP, così come ormai in tutti i linguaggi, esiste il concetto di OOP (Object Oriented Programming), fondamentale per la gestione dei dati in maniera catalogata e strutturata.

I vantaggi della OOP sono innumerevoli dal punto di vista tecnico ma anche per quanto riguarda la progettazione; in particolar modo grazie alla OOP:

  • E' possibile definire al meglio le entità in gioco che dovranno relazionarsi fra loro per la generazione e la gestione delle informazioni
  • E' possibile strutturare un software ragionando sulla base di concetti reali e comportamenti fra le entità
  • E' possibile creare un software maggiormente scalabile nel tempo ed aperto all'integrazione con nuove entità
  • E' possibile utilizzare più volte una stessa entità su progetti differenti

Per poter usufruire al meglio della OOP, occorre innanzitutto comprendere al meglio la definizione e l'utilizzo degli oggetti o delle entità, chiamate in termine tecnico classi.

Programmazione ad oggetti

Le classi definisco esattamente un'entità nelle sue informazioni (attributi) e nelle sue funzionalità (metodi).
Nella definizione di un progetto, il primo passo fondamentale consiste sempre nel riconoscimento e nella creazione delle classi in modo tale da avere sempre una visione completa delle entità in relazione fra loro nell'ambiente di sviluppo.

Una delle entità maggiormente utilizzate è senza dubbio quella dell'Utente.
Volendo creare dunque una classe per l'utente, avremmo sicuramente degli attributi di base come ad esempio il nome, cognome o la data di nascita.
Per quanto riguarda i metodi invece, ovviamente questi cambieranno in funzione anche dell'applicativo, ma generalmente ci sono alcune funzionalità sempre presenti e dunque riutilizzabili, come ad esempio il calcolo dell'età a partire dalla data di nascita.

Ebbene individuare sempre i metodi e gli attributi oltre che le classi, può agevolare di gran lunga il lavoro di sviluppo del software.

Programmazione ad oggetti

Prima di analizzare la realizzazione delle classi con il PHP, proviamo ad effettuare una progettazione dell'architettura, partendo dall'esercitazione sui Database per il gestionale di Trenitalia. Per la progettazione delle classi con standard UML si può utilizzare lo strumento Visual Paradigm

Premessa
Nella definizione di una classe, che sia su carta o su pc, si utilizza lo schema dello standard UML.

  • La classe si rappresenta all'interno di un rettangolo. Nella parte superiore si definisce il nome della stessa, successivamente gli attributi e con una linea separatoria si suddivisono i metodi
  • Il nome della classe deve iniziare sempre con una lettera maiuscola
  • Il nome degli attributi e dei metodi deve essere sempre tutto scritto in minuscolo e quanto più esplicativo possibile, separando eventuali termini dal simbolo dell'underscore
  • Il nome dei metodi deve essere sempre seguito dalle parentesi per identificare appunto una funzione specifica sulla classe
  • Gli attributi di una classe possono essere anche istanze di altre classi e si indicano con la dicitura "attributo:Classe". In questo modo l'attributo potrà usufruire di tutti gli attributi e metodi appartenenti alla classe istanziata.

Programmazione ad oggetti

Per poter creare una classe in PHP, si crea un file che inizi con il nome stesso della classe (lettera maiuscola inclusa).

<?php
# File Utente.php

/**
* Descrizione della classe necessaria per una corretta documentazione del codice
*/
class Utente {
	# Attributi

	/**
	* @var string 	Documentazione corretta per l'attributo
	*/
	$nome;
	$cognome;
	$data_nascita;

	# Metodi

	/**
	* Anche per il metodo occorre integrare una documentazione
	*/
	function calcola_eta() {...}

}

		

Programmazione ad oggetti

La definizione essenziale di una classe è dunque di per se molto semplice.
E' possibile però definire al dettaglio anche la visibilità degli attributi e dei metodi della classe, per tutte le altre classi o elementi che interagiranno con la stessa, al fine di proteggere eventuali informazioni.

I metodi e gli attributi possono avere quattro definizioni differenti:

  • public - tutto ciò che è pubblico, può essere utilizzato liberamente e senza alcuna restrizione. L'opzione public, è quella utilizzata di default se non viene specificato null'altro.
  • private - tutti gli elementi privati, possono essere utilizzati esclusivamente all'interno della classe
  • protected - tuttli gli elementi protetti, possono essere utilizzati solamente dalla classe e da eventuali classi derivate
  • static - gli elementi statici possono essere accessibili senza dover istanziare l'oggetto della classe

Si ricorda che il termine istanza della classe indica la dichiarazione all'interno del codice PHP di una variabile specifica che conterrà tutti gli attributi e i metodi della classe.

Di seguito una serie di casistiche per migliorare la comprensione della teoria appena descritta.

Programmazione ad oggetti

Focalizziamo l'attenzione sull'uso delle diverse tipologie esclusivamente sugli attributi della classe Utente.

<?php
class Utente {
	public $id;
	private $nome;
	protected $cognome;
	static $data_nascita;
}
		

Proviamo ora ad istanziare la classe Utente e ad accedere ai suoi attributi.

<?php
require_once("Utente.php");

$data_nascita_ut = Utente::data_nascita; # Riconoscimento attributo static

$istanza_utente = new Utente(); # Istanza della classe
$id_ut = $istanza_utente->id; # Riconoscimento dell'attributo id pubblico
$nome_ut = $istanza-utente->nome; # ERRORE l'elemento è private e dunque non accessibile
$cognome_ut = $istanza-utente->cognome; # ERRORE l'elemento è protected e dunque non accessibile

		

Programmazione ad oggetti

Dalla casistica precedente, abbiamo dunque notato che:

  • Per poter istanziare una classe si utilizza la dicitura new Nomeclasse()
  • Per accedere agli attributi o ai metodi della classe, si utilizza la variabile di istanza, seguita dal simbolo "->"
  • Per gli elementi dichiarati static non è necessario utilizzare l'istanza della classe, ma si può accedere semplicemente utilizzando la dicitura Nomeclasse::attributo oppure nel caso di un metodo Nomeclasse::metodo()

Si capisce dunque che anche in fase progettuale (UML) è necessario definire al meglio la visibilità dei metodi e degli attributi al fine di offrire al meglio le funzionalità di ciascuna classe per l'integrazione con altre classi o per l'utilizzo nel codice.

Programmazione ad oggetti

Se dall'interno della classe si vuole accedere agli attributi della stessa, si utilizza il costrutto $this, come mostrato di seguito:

<?php
class Utente {
	public $id;
	private $nome;
	protected $cognome;
	static $data_nascita;

	public function generalita() {
		return $this->nome." ".$this->cognome;
	}
}
		

Per quanto riguarda gli attributi o metodi statici, occorre utilizzare il costrutto self:

<?php
	public function calcola_eta() {
		$data_nascita_utente = self::data_nascita;
	}
		

Programmazione ad oggetti

Fra i concetti fondamentali della programmazione ad oggetti, ci sono due caratteristiche specifiche:

  • Ereditarietà
    Possibilità di creare una serie gerarchica di classi per il riutilizzo di metodi e attributi
  • Polimorfismo
    Possibilità di ridefinire per ciascuna classe che discende da un'altra classe, i metodi e gli attributi eredeitati

Queste caratteristiche delle classi, permettono dunque una strutturazione molto più dettagliata.
Per comprendere al meglio il concetto di ereditarietà e polimorfismo, analizziamo gli esempi di seguito.

Programmazione ad oggetti

<?php
# Animale.php

class Animale {
	public $razza;
	public $zampe;

	/**
	* Il metodo __construct è un magic mathod del PHP, richiamato al momento
	* dell'istanza della classe.
	* Questo metodo accetta due parametri in ingresso.
	*/
	public function __construct($razza_animale, $zampe_animale) {
		$this->razza = $razza_animale;
		$this->zampe = $zampe_animale;
	}

	public function stampa_dati() {
		echo $this->razza." - ".$this->zampe;
	}
}			
		

Programmazione ad oggetti

Abbiamo dunque definito una classe generica Animale, con un costruttore, oltre che un metodo e due attributi. Per costruttore si intende un metodo che sarà richiamato in automatico al momento dell'istanza dell'oggetto. Per dichiarare un costruttore della classe, si può utilizzare il magic method di PHP "__construct" oppure creare un metodo che si chiami esattamente come la classe.

Se adesso volessimo creare una classe specifica per ciascun animale, potremmo già far riferimento alla classe generica Animale, ereditando attributi e metodi per un riutilizzo.

Definiamo ad esempio la classe Cane specificando che estende la classe Animale:

<?php
# Cane.php

class Cane extends Animale {
	public function stampa_verso() {
		echo "Bau!";
	}
}			
		

Programmazione ad oggetti

La classe Cane come si può notare, riporta un solo metodo.
A differenza di quanto si può vedere però, la classe ha in realtà anche degli attributi e altri due metodi, che sono quelli ereditati dalla Classe Animale. Si potrà dunque utilizzare:

<?php
	# Istanza della classe con passaggio di parametri, così come specificato nel costruttore
	$fido = new Cane("Pastore Tedesco", 4); 

	# Stampa dati (metodo ereditato da Animale)
	$fido->stampa_dati();

	# Stampa verso (metodo proprio di Cane)
	$fido->stampa_verso();
		

Grazie al concetto di ereditarietà, è possibile dunque non solo creare una gerarchia, ma evitare di riscrivere metodi e attributi riutilizzando al meglio il codice.
Creare dunque un nuovo animale, non sarà un problema!

Programmazione ad oggetti

Per quanto riguarda il concetto di polimorfismo, altro non è che la possibilità di sovrascrivere un metodo o un attributo da parte delle classi che ereditano le informazioni da una classe generica.

Se per esempio avessimo voluto applicare un comportamento diverso al metodo stampa_dati() dichiarato in Animale, per la classe Cane:

<?php
class Cane {
	public function stampa_dati() {
		echo "Sono un cane di razza ".$this->razza." con ".$this->zampe." zampe";
	}
}
		

In questo modo ogni sottoclasse potrà predisporre un comportamento differente per uno specifico metodo, mantenendo dunque una elevata flessibilità.

Pattern MVC

La logica alla base dei nuovi standard di sviluppo

Pattern MVC

Fino ad oggi abbiamo immaginato l'architettura di un software sul web, come una comunicazione lineare fra Client e Server, dove ad una specifica richeista del CLient attraverso il browser, corrispondeva un processo PHP con eventuali interrogazioni al database, che restituivano una specifica pagina HTML.

Ma cosa sarebbe stato se questo approccio fosse rimasto invariato nel tempo?
Probabilmente non saremmo mai arrivati ad avere social network all'avanguardia, oppure un'evoluzione così importante sul web e nel mondo delle app sui nostri smartphone.
Può sembrare un paradosso, eppure è la realtà.

Come visto anche nei precedenti moduli, seppur non troppo complesso, gestire un applicativo con un approccio sequenziale era complicato in maniera direttamente proporzionale alla grandezza dell'applicativo stesso.
Per ogni pagina web si andavano a creare specifiche pagine, con nomenclature libere e nessuna vera regola da seguire dal punto di vista architetturale e strutturale.

Per non parlare della capacità di lavorare in team su un unico progetto.

Pattern MVC

Per metter fine a questa confusione sono stati definiti nel tempo diversi modelli, definiti con il termine pattern da applicare alla programmazione sul web per una più corretta evoluzione.

In seguito a innumerevoli tentativi, si è arrivati alla definizione di uno specifico pattern che è ad oggi quello utilizzato nel 99,99999% delle applicazioni web e mobile, ovvero il pattern MVC.

MVC è l'acronimo di Model - View - Controller ed è un pattern di programmazione molto potente, che ha permesso sui software web based:

  • Scalabilità - possibilità di gestire applicativi con crescita esponenziale nel tempo
  • Progettazione - definizione dell'architettura e della struttura ben precisa per il software
  • Integrazione - possibilità di interagire con più risorse esterne all'applicativo
  • Condivisione - accesso semplificato per tutti gli sviluppatori al progetto
  • Collaborazione - sviluppo contemporaneo al codice sorgente da parte di più risorse

Ed è proprio grazie a questo pattern che il web è riuscito a predominare nel giro di pochissimo tempo e coinvolgendo un numero elevatissimo di figure professionali differenti.

Pattern MVC

Alla base del pattern, c'è la distinzione ben precisa dei tre componenti fondamentali:

  • Model
    Utilizzato per accedere alle infomrazioni di back-end (database) dell'applicativo e preparare tutti i dati da mostrare all'utente attraverso la pagina web.
  • View
    Pagina finale elaborata dal back-end e mostrata all'utente finale
  • Controller
    Intermediario fra la View e il Model, permette di riconoscere la richiesta dell'utente, gestire l'elaborazione da parte del Model e restituire all'utente stesso la View risultante

Pattern MVC

Pattern MVC

Sulla base dei tre componenti fondamentali, ci sono poi ulteriori elementi che entrano in gioco, in particolar modo per quanto riguarda il livello del Model per la gestione delle informazioni:

  • DAO
    Acronimo Data Access Object è il componente che permette al model di accedere alle informazioni del database, ovvero l'unico elemento che deve gestire le query all'interno dell'applicativo
  • VO
    Acronimo di Value Object è il componente che contiene tutte le informazioni delle tabelle del database, per semplificare la creazione e manipolazione delle query
  • Helper
    Funzioni generiche di supporto per l'elaborazione delle informazioni, che non devono assolutamente includere operazioni con il database

Pattern MVC

Pattern MVC

Come si può iniziare a comprendere dall'immagine della struttura, l'introduzione del pattern permette una distinzione ben definita di tutti i componenti in gioco per quanto riguarda l'architettura del software.
In questo modo sarebbe possibile far collaborare direttamente già tre risorse distinte nella realizzazione, ovvero:

  • una risorsa progettuale in grado di definire le entità in gioco (Model) e i database per la generazione di DAO (query)
  • una risorsa di business logic, per l'integrazione della logica all'interno del back-end sui model
  • una risorsa di front-end, per la configurazione delle view ovvero e dunque dell'interfaccia

Pattern MVC

Nella fase di avvio di un nuovo progetto nell'ottica del pattern MVC, occorrerebbe dunque seguire al meglio il processo di progettazione nei seguenti step:

  • Definizione del database - essendo la logica del Model al centro del progetto di back-end, occorre definire subito le caratteristiche del database e le tabelle principali
  • Riconoscimento delle classi - partendo dal database, si vanno a definire le classi in gioco, ovvero gli elementi protagonisti del software, sui quali dovranno esser svolte le maggiori operazioni
  • Progettazione della UI - definendo l'interfaccia delle View, si possono capire quali saranno le informazioni che il Model dovrà fornire al controller per ciascuna richiesta. In questo modo lo sviluppatore di back-end saprà esattamente quali interrogazioni effettuare al database e quali processi impostare

Pattern MVC

Dal punto di vista pratico, ovvero applicando la logica MVC su una struttura di back-end PHP:

  • i Model altro non sono che le classi sulle quali creare i metodi specifici
  • i DAO sono classi con i soli metodi per la gestione delle query
  • i VO sono classi che contengono esclusivamente gli attributi legati al DAO e al Model
  • gli helpers sono funzioni classiche del PHP, non correlate ad alcun Model e che non richiedono query al database
  • i Controller sono classi PHP con soli metodi che richiamano a loro volta istanze di Model per l'utilizzo di metodi specifici, e includono una View per la visualizzazione lato utente

Di seguito alcuni esempi di ciascuna tipologia di elementi che compongono il pattern MVC.
Esaminiamo la casistica di un utente e tutte le funzionalità che si trovano per la gestione di una registrazione.

Pattern MVC

VO

I VO altro non sono che classi con soli attributi. Secondo gli standard di una buona programmazione, per ciascuna tabella del database, deve esistere un DAO con un VO associato nel progetto web.
Tutti gli attributi del VO, devono dunque corrispondere ai campi del database.

<?php

class Utente_VO {
	$id,
	$nome,
	$cognome,
	$data_nascita;

	/*
	* Metodo per ricevere tutte le informazioni del VO sotto forma di array associativo
	*/
	public function to_array() {
		return get_object_vars($this);
	}
}			
		

Abbiamo inoltre creato un metodo generico, che permetterà di utilizzare gli attributi del VO sotto forma di array, utile per la manipolazione e la gestione all'interno del DAO.

Pattern MVC

DAO

I DAO contengono invece tutte le operazioni per la specifica tabella sul database e sono generalmente legati al Model dell'entità che rappresentano oltre che al VO che contiene tutte le informazioni (campi) della tabella.

<?php
class Utente_DAO {
	private $nome_tabella;
	private $primary_key;
	public $vo;

	public function __construct() {
		$this->nome_tabella = "utente";
		$this->primary_key = "id";
	}

	public function inserisci() {
		# Formatto il VO per la query
		$query = "INSERT INTO ".$this->nome_tabella." SET ";
		foreach($this->vo AS $attributo => $valore) 
			$query .= $attributo." = '".$valore."', ";
		$query = substr($query, 0, -1);
		
		# ... esecuzione e gestione della query
	}
}			
		

Pattern MVC

Model

I Model sono invece classi responsabili dell'elaborazione dei dati e delle informazioni che il Controller dovrà poi mettere a disposizione della View. Sono inoltre gli unici elementi che hanno accesso ai DAO e dunque alla manipolazione del database.

<?php
class Utente {
	static function registrazione($vo) {
		# Istanza del DAO
		$dao = new Utente_DAO();

		# Controllo dei campi
		if(strlen($vo->nome) > 0 AND strlen($vo->cognome) > 0) {
			$dao->vo = $vo;
			$dao->inserisci();
		}else
			return false;
	}
}			
		

Abbiamo dichiarato il metodo come static in modo da accedere agevolmente senza il bisogno di istanza.

Pattern MVC

Controller

I Controller sono dunque classi che permettono di riconoscere la richiesta dell'utente ed eventuali parametri in entrata, e restituire delle informazioni elaborate, facendo riferimento all'interfacciamento con i Model.

<?php
class Utente_Controller {
	public function registrazione_utente() {
		$vo = new Utente_VO();
		$vo->nome = $_POST["nome"];
		$vo->cognome = $_POST["cognome"];
		$vo->data_nascita = $_POST["data_nascita"];

		Utente::registrazione($vo);

		# Caricamento della View
		# ...
	}
}			
		

Il Controller del caso, gestisce dunque i parametri in POST provenienti da un form e si affida al Model Utente per il controllo e l'inserimento dei dati per la registrazione.

Gestione degli accessi

Controllo delle richieste e routing

Gestione degli accessi

Appresa al meglio la logica del pattern MVC e la manipolazione delle classi, non resta che effettuare dei test operativi.
Prima dell'esercitazione però, è bene soffermarsi ancora un istante su una nozione molto importante, ovvero la gestione delle richieste e la manipolazione delle rotte.

In sostanza: come si passa dalla richiesta lato browser (URL) all'attivazione dei controller e dunque del processo MVC che restituirà una View finale all'utente?

Il primo step che occorre fare è senza dubbio un'impostazione delle regole proprio per le URL, che devono essere in grado di determinare quasi autonomamente, il comportamento del processo MVC.
La buona prassi dice che nell'architettura MVC, le URL devono essere sempre formattate nella seguente modalità:

http://nomesito.it/controller/action/

Occorre dunque specificare in maniera chiara il nome del controller in ascolto per la chiamata e l'action, ovvero il metodo presente nel controller, che deve gestire la richiesta.
Nella casistica precedente vista per il processo di registrazione utente, la URL generata dovrebe essere dunque qualcosa del tipo http://nomesito.it/utente_controller/registrazione_utente/.

Questa URL non è però molto user friendly e SEO friendly. Occorre modellarla ancora un po'.

Gestione degli accessi

Prima di rendere più leggibile la URL, occorre impostare il meccanismo che eviti l'inserimento della pagina PHP o HTML che deve essere visualizzata. Infatti probabilmente avrai notato che nell'URL precedente, non vi è alcun richiamo alla pagina index.php o altro. Tutto quanto deve essere comandato esclusivamente dall'URL generica.

Per impostare questo comportamento "anomalo" rispetto a quanto visto fino ad oggi, si utilizza il file .htaccess; questo file è ricercato dal browser ad ogni caricamento ed effettua diversi controlli che possono essere utilizzati per la sicurezza e per la manipolazione delle richieste.

Il file .htaccess va creato all'interno della document root del portale web, ovvero a livello della pagina index.php.

Per poter abilitare il funzionamento di questa impostazione, occorre modificare il file di configurazione di Apache e abilitare il modulo mod_rewrite con Override All.

Gestione degli accessi

Una prima configurazione che possiamo creare per il file .htaccess è proprio la possibilità di riconoscere controller e action nella richiesta. Tutto deve però essere sempre gestito dalla pagina index.php.
Si vanno dunque a definire delle regole all'interno del file, che tramite espressioni regolari permetteranno il riconoscimento della richiesta e associeranno un comportamento.

<IfModule mod_rewrite.c>
	Options +FollowSymlinks
	RewriteEngine On

	# Regola per il riconoscimento della richiesta controller/action/
	RewriteRule ^([a-zA-Z0-9\_\-]+)/([a-zA-Z\_\-]+)/$ index.php?controller=$1&action=$2 [L]
</IfModule>			
		

Analizzando il codice, creiamo un modulo per il mod_rewrite (IfModule) all'interno del quale abilitiamo la proprietà di rewrite (RewriteEngine On), grazie alla quale non diventa obbligatorio specificare la pagina all'interno dell'URL.
Successivamente definiamo una regola generica, attraverso l'espressione regolare, tale per cui se l'URL contiene due parametri (i parametri sono valori separati dal simbolo slash /), viene richiamata in automatico la pagina index.php, con due parametri in GET, ovvero appunto controller e action.
In questo modo, solo grazie a questa regola, avremo un controllo ottimale delle richieste per il nostro modello MVC. Successivamente avremo comunque modo di ampliare il discorso sull'htaccess.

Gestione degli accessi

Abbiamo dunque impostato un meccanismo tale per cui tutte le richieste che arrivano da URL, vengono smistate sulla pagina index.php con due parametri in entrata via GET. Non resta dunque che gestire questi parametri per il corretto richiamo all'apposito metodo del controller necessario per l'elaborazione.

<?php
$controller = $_GET["controller"];
$action = $_GET["action"];		

# Verifico l'esistenza del file per il controller
if(file_exists($controller.".php")) {
	include $controller.".php";

	# Verifico l'esistenza della classe del controller e creo un'istanza
	if(class_exists($controller)) {
		$controller_obj = new $controller();
		
		# Verifico l'esistenza del metodo (action) sulla classe e lo richiamo
		if(method_exists($controller_obj, $action)) {
			$controller_obj->$action();
			# Includo View
		}
	}
}
		

Così facendo per ogni richiesta, l'index smisterà a chi di dovere il compito dell'elaborazione.

Gestione degli accessi

Volendo evitare di riportare nella URL il nome completo del controller, si può pensare anche ad una gestione nella index.php che permetta di completarlo per una maggiore leggibilità.

Se dunque si decide di applicare per tutte le classi dei controller, la dicitura "_Controller", al momento della lettura del parametro in GET, sarà sufficiente inserire quanto segue:

<?php
$controller = $_GET["controller"]."_Controller";
		

In questo modo l'URL sarà molto più leggibile e non si perderà la funzionalità.
http://nomesito.it/utente/registrazione_utente/

Gestione degli accessi

Uno dei problemi più frequenti che si può incontrare, è la necessità di dover includere di volta in volta tutte le classi per i Model, i DAO e i VO.
Per ovviare a questo problema, si utilizza la tecnica del lazy loading, ovvero un "caricamento pigro" che include automaticamente tutte le classi necessarie per averle a disposizione nel software senza doverle richiamare.

Per sfruttare al meglio questa opzione, si consiglia la suddivisione delle classi in apposite cartelle (es. DAO, VO, Model e Controller).
Successivamente potremo sfruttare la funzione di lazy loading:

<?php
spl_autoload_register(function ($class_name) {
	if(file_exists("vo/" . $class_name . ".php")) require_once "vo/" . $class_name . ".php";
	if(file_exists("dao/" . $class_name . ".php")) require_once "dao/" . $class_name . ".php";
	if(file_exists("model/" . $class_name . ".php")) require_once "model/" . $class_name . ".php";
});
		

Per i controller si consiglia di caricarli invece manualmente solo nel caso in cui la richiesta lo preveda, per evitare un caricamento eccessivo di risorse.

Esercitazione

Applicazione del OOP e pattern MVC con gestione degli accessi

Esercitazione

Per prendere confidenza con il sistema OOP, il pattern MVC e la gestione degli accessi, ricreare la struttura del social network impostato nell'esercitazione di base.

In particolar modo rispettare i seguenti requisiti e step:

  • Creare una progettazione del sistema OOP su modello UML
  • Creare almeno una classe generica DAO da estenedere per tutti i DAO nelle operazioni di CRUD, in modo da evitare la riscrittura delle stesse query su tutti i modelli
  • Per tutte le chiamate AJAX, attualmente utilizzate come API, creare Controller specifici e impostare una regola appropriata sul file .htaccess per la distinzione fra le API e le chiamate standard alle pagine

<Thank u!>

Sempre pronto a darti una mano