Laravel e Symfony sono due framework PHP. La release 1.0 di Symfony risale a Gennaio 2007, mentre l’ultima, la 3.2, è stata rilasciata nel Novembre 2016. Laravel 1 è uscita qualche anno dopo, nel Giugno 2011, mentre la versione corrente è la 8, rilasciata nell’Ottobre 2020.
Scontro fra titani Laravel vs Symfony
Chiariamo subito un aspetto importante: entrambi i framework sono molto validi, simili per certi aspetti e con numerose funzionalità out of the box.
Laravel utilizza alcune componenti di Symfony. Questo non significa che queste componenti siano state incluse in Laravel come un semplice copia e incolla: alcune sono state modificate, ad altre invece sono state aggiunte funzionalità, e altre ancora sono state semplicemente riadattate al nuovo ecosistema.
Anche se Laravel e Symfony hanno alcune componenti in comune, questi framework PHP sono diversi. Una delle differenze principali sta nel modo in cui è scritto il codice. L’opinione comune è che Laravel abbia un approccio molto semplice e pulito, che riesce a far risparmiare tempo allo sviluppatore, Symfony, invece è un po’ più complicato.
Le differenze tra Laravel e Symfony
Ciò che segna una netta divergenza fra le due filosofie è la separazione dei componenti: Symfony, come detto, lascia molta libertà di utilizzare in maniera indipendente le sue varie parti, anche in altri progetti. Laravel, al contrario, si basa su un pattern facade, grazie al quale abbiamo un codice semplice e pulito che, in realtà, è espressione di librerie molto complesse. Allo stesso tempo permette un’estrema personalizzazione dei progetti, grazie all’integrazione di componenti di terze parti.
Un’altra differenza sostanziale è che tramite Laravel è possibile utilizzare il template engine Blade, il cui punto di forza rispetto a Twig (il suo rivale, unico engine utilizzabile da Symfony) è la semplicità: la sintassi è estremamente intuitiva e rapida da assimilare, in pochi minuti si familiarizza con la struttura a sezioni e la rapidità con la quale si utilizza l’ereditarietà delle altre pagine (comunemente, si utilizza una vista master come base per tutte le altre).
Performance
Partiamo dal presupposto che se la vostra priorità è la performance, vi consigliamo di scegliere un framework più leggero e prestante come Phalcon o Slim. Dipende dal numero di chiamate al secondo che pensate di dover soddisfare.
Nella nostra comparazione ci affidiamo a un semplice test fatto da Taylor Otwell in cui dopo un’installazione pulita dei due framework ha eseguito un test utilizzando Apache benchmark e questi sono i risultati:
- Laravel: 609.03 request al secondo
- Symfony: 532.97 request al secondo
Lieve differenza in favore di Laravel.
L’ORM: il gigante e la farfalla?
L’ORM utilizzato dai due framework merita, a nostro avviso, un’analisi a parte. Installando Symfony troviamo Doctrine 2 che, rispetto al concorrente Eloquent, è probabilmente un passo indietro rispetto alla programmazione moderna: difatti per modellare e utilizzare le entità dovremo usare il “vecchio” PHP, mentre con Eloquent andremo ad estendere l’omonima classe su tutte le altre classi che andremo a creare, dove erediteranno tutte le comode funzioni native.
Un punto a favore di Doctrine 2 è sicuramente DQL, un linguaggio dedicato alle query, estremamente potente, grazie al quale abbiamo un controllo totale del nostro database, cosa che non sempre accade con il Query Builder di Laravel, poco versatile nelle query più complesse.
Un altro esempio classico sulla differenza tra i due approcci è il salvataggio dei dati nel database: Eloquent, con il comando save(), memorizza automaticamente nel nostro DB i dati che abbiamo passato alla nostra classe. Doctrine 2, invece, ha bisogno di una classe di servizio chiamata Entity Manager, che va richiamata addirittura 2 volte consecutive per effettuare due operazioni distinte, chiamate persist e flush. Anche la ricerca di record è leggermente più complessa rispetto a Eloquent e necessita ancora della classe Entity Manager.
Nonostante ciò, Doctrine 2 è un ORM eccellente, sotto alcuni aspetti anche più di Eloquent, ma la sua complessità lo rende probabilmente poco versatile nella maggior parte delle applicazioni.
E quindi, scelgo Laravel?
Per noi, ovviamente sì (sarebbe preoccupante se su LaraMind non fosse così, a pensarci bene). Abbiamo parlato molto delle peculiarità del nostro framework preferito ma vogliamo concludere con quello che, secondo noi, è il vantaggio più grande di Laravel: la curva di apprendimento.
Con Laravel è possibile imparare rapidamente le funzioni più importanti, necessarie per mettere online il proprio progetto facendolo funzionare con una certa efficacia, senza tanti fronzoli. Parallelamente, man mano si prende confidenza con il framework, si evolvono costantemente le proprie capacità, limando i difetti e migliorando le prestazioni e l’eleganza del software.
Recensione un pochetto di parte. 🙂
Eloquent è sicuramente un orm funzionale, ma come si può affermare che doctrine sia un passo indietro?
Il fatto che servano due comandi distinti (persist e flush) è per dare la possibilità al programmatore di decidere quando effettuare realmente l’operazione di scrittura nel db, operazione onerosa se si devono scrivere molteplici oggetti.
Per l’estensione della classe o dell’oggetto separato lo ritengo un fatto puramente accessorio con i suoi vantaggi/svantaggi: doctrine mi lascia libero di estendere le classi che mi pare ma mi costringe ad istanziare un oggetto, eloquent un po’ il contrario. Insomma de gustibus.
Saluti
Sulla parte di framework posso anche trovarmi d’accordo, anche se io personalmente preferisco symfony e soprattutto twig, ma sulla parte di ORM mi sento di dire che al massimo è il contrario, ovvero doctrine è 2 passi avanti a eloquent.
Non conosco Symphony, ma da diverso tempo uso Laravel e devo dire che è un ottimo framework.