Per progetti di una certa complessità l’uso di Symfony può aiutare, e non poco, uno sviluppatore PHP. Ho studiato Symfony circa un anno fa, ma già da un po’ di tempo soffrivo l’eccessivo uso della console e il fastidio di dover mettere mano più a file yaml che a codice PHP. Mi sono guardato attorno, mi sono messo a smanettare su progetti personali, sono passato a Django e infine ho ceduto al consiglio di un amico rubysta che mi consigliava CakePHP.
La learning curve di questo simpatico framework è eccezionale. In un paio di giorni si riesce a padroneggiarlo in modo da poter mettere su una piccola applicazione dotata di tutti i meccanismi necessari per essere rilasciato in ambiente di produzione. Le performance mi sembrano buone, ma non ho avuto modo di testarle a fondo. A occhio comunque dovrebbe risultare più leggero di Symfony e più scattante. Assomiglia a Django e, fidandomi del rubysta, linguaggio che non conosco, assomiglia parecchio a Rails.
In questi giorni ho avuto modo di apprezzare che i tempi di sviluppo sono più corti rispetto al corrispettivo in Symfony. E, parere del tutto personale, mi diverto di più a smanettare su codice PHP piuttosto che sui file yaml che accompagnano lo sviluppo in Symfony.
Ho letto diversi pezzi che presentano CakePHP in modo sicuramente superficiale, descrivendolo semplicisticamente. Il che non corrisponde al vero. Almeno nell’ultima release stabile che ho per le mani posso affermare di non sentire la mancanza di certi meccanismi in Symfony. Certo il numero di plugin di cui dispone quest’ultimo è incommensurabile rispetto a CakePHP, ma penso si riesca benissimo a supplire con una buona progettazione del codice e magari la scrittura di librerie proprie.
A primo impatto ho nelle directory solo e soltanto i file che mi servono davvero e riesco ad avere un quadro d’insieme che in Symfony non era così chiaro.
Devo ancora approfondire il capitolo sicurezza, ma ho letto buone cose su validazione e sanitization dei dati, su ACL e sessioni. I primi giudizi non possono che essere positivi, dunque. Ho intenzione di provarlo fra qualche settimana su un mini portale che non richiede uno sviluppo particolarmente complesso. Soprattutto voglio capire se scala bene su una VPS e quanto traffico è in grado di supportare senza risentirne in termini di banda e reattività.
Non ho ancora preso contatto con la comunità italiana, per cui sono curioso di conoscere le vostre opinioni su questo framework. Le mie impressioni iniziali sono esatte?
12 Commenti
Pingback: Tweets that mention Un framework PHP dal gusto dolce: CakePHP | Francesco Corsentino .net -- Topsy.com
ciao, un paio di settimane fa ho fatto anch’io delle prove con vari framework ed alla fine ho scelto Yii per questi motivi: documentazione, pulizia del codice, modularità, flessibilità.
CakePHP l’ho scartato perchè era già strutturato, nel senso che pone dei vincoli di architettura e design, che può essere un vantaggio per costruire applicazioni web di un certo tipo.
Yii è più adatto per essere usato come base per costruire qualsiasi tipo di applicazione web implementando TDD, patterns, jquery.
@markux grazie della segnalazione di Yii che in effetti mi era un po’ sfuggito. Nel fine settimana lo proverò. Alla fine credo dovrò tornare a potenziare quello mio personale, che è molto confuso perché non ha seguito un percorso lineare e coerente. Ci metto le mani una volta ogni tanto e lo modifico quando termino di studiare BENE determinati argomenti.
Sui vincoli su architettura e design devo dire che per adesso non ho notato svantaggi. O meglio, svantaggi per quanto concerne l’applicazione che dovrò mettere su. Che probabilmente è poi l’applicazione di un certo tipo di cui tu parlavi nel commento.
Provo Yii e proverò a tirare le somme. Grazie ancora della segnalazione.
Pingback: Il punto della settimana #32 | Francesco Corsentino .net
prova anche codeigniter.com
Ciao @Tech, provato, ma non mi piace.
Il vero grande problema di CakePHP è l’ORM. Gli oggetti restituiti dall’ORM di CakePHP sono array e non classi. Doctrine, utilizzato da Symfony, è molto più versatile da questo punto di vista: una query eseguita da Doctrine restituisce un oggetto per così dire “vivo”; solo per fare un esempio, se si richiede all’oggetto di recuperare un dato conservato su una tabella relazionata, l’oggetto è in grado di eseguire autonomamente la query in modalità lazy-loading. Niente di tutto questo è possibile con CakePHP e per questo esistono vari workaround (come il Behaviour Containable).
Il fatto che l’ORM di CakePHP non restituisca classi ma array è davvero un grosso vincolo, e lo si rileva appena la complessità dell’applicazione che si vuole sviluppare supera una soglia abbastanza bassa.
È in atto un tentativo di integrazione di CakePHP con Doctrine (uno dei leader del team di sviluppo di CakePHP ha lasciato il gruppo ed ha intrapreso proprio quella strada, sviluppando questo Framework http://lithify.me, sostanzialmente CakePHP+Doctrine)
Symfony è effettivamente molto più burocratico e verboso di CakePHP. Ma è anche vero che l’ORM di CakePHP è davvero il suo tallone di Achille.
Commento preciso e puntuale.
Preciso perché sei stato veramente esaustivo in merito all’ORM. Il problema che tu descrivi è reale quando stai costruendo una applicazione di una certa complessità. Ma, limitatamente a una piccola utility o un piccolo sito web, almeno questa è la mia attuale esperienza, il limite è facilmente superabile o, se vuoi, ignorabile. In effetti sono rimasto un attimo sorpreso dalla gestione del database. All’inizio ho usato pesantemente la funzione debug per capire come mi venivano restituiti i risultati. Adesso non mi pesa, però è indubbio che se l’applicazione cresce, crescerà anche la complessità del codice dentro CakePHP.
Su Doctrine nulla da eccepire, e ci mancherebbe. Credo sia l’ORM più bello che mi sia capitato tra le mani. E sono cosciente del fatto che non ho raggiunto il giusto livello di esperienza con questo favoloso strumento. Grazie per la segnalazione di CakePHP+Doctrine, beh se riuscissero a fare un buon lavoro lo adotterei all’istante.
Doctrine è un bel prodotto, in effetti.
Se hai modo, dai un occhio a Hibernate, l’ORM per Java dal quale Doctrine ha preso ampiamente ispirazione. Penso che quello sia tra gli ORM più eccellenti che mi sia capitato di usare.
Per quanto riguarda CakePHP e Doctrine, anche senza stare ad attendere il completamento di Lithium, posso suggerirti questo link:
http://dqminh.com/integrate-doctrine-orm-with-cakephp-part-1
In realtà, ho scoperto che non è poi così difficile utilizzare Doctrine dentro CakePHP. Io ho fatto così:
1. Copi Doctrine in vendor
2. Prepari uno script di bootstrap per Doctrine, con grossomodo questo codice:
require_once(APP . "/docmodels/compiled/AllModels.compiled.php");
spl_autoload_register(array('Doctrine', 'autoload'));
$manager = Doctrine_Manager::getInstance();
App::import('Core', "ConnectionManager");
$db = ConnectionManager::getDataSource('default');
$config = $db->config;
$dsn = "mysql:dbname={$config['database']};host={$config['host']}";
$user = $config['login'];
$password = $config['password'];
$dbh = new PDO($dsn, $user, $password);
$conn = Doctrine_Manager::connection($dbh);
$options = array('packagesPrefix' => 'Package',
'packagesPath' => '',
'packagesFolderName' => 'packages',
'suffix' => '.php',
'generateBaseClasses' => true,
'generateTableClasses' => true,
'generateAccessors' => true,
'baseClassPrefix' => 'Base_',
'classPrefixFiles' => false,
'classPrefix' => 'd', // Le classi Doctrine avranno il prefisso d*
'baseClassesDirectory' => 'generated',
'baseClassName' => 'Doctrine_Record',
);
$manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
$manager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true);
$manager->setAttribute(Doctrine::ATTR_MODEL_LOADING, Doctrine::MODEL_LOADING_CONSERVATIVE);
$manager->setAttribute(Doctrine::ATTR_VALIDATE, Doctrine::VALIDATE_ALL);
Doctrine::loadModels(APP . '/docmodels');
3. Usi Doctrine dai Controller di Cake
function getElencoByOccupante($key) {
App::import('Vendor', 'Doctrine', array('file' => 'bootstrap.php'));
$q = Doctrine_Query::create()
->from('dUtente u')
->innerJoin('u.Post p')
->where("p.testo LIKE "%{$key}%"")
;
return $q->execute()->toArray(true);
}
Il risultato di toArray() è perfettamente compatibile a quello che otterresti con l’ORM di CakePHP, tranne per il fatto che puoi finalmente smettere di impazzire con le relazioni, il Behavior Containable e le maledette relazioni molti-a-molti (hai mai provato a fare una query con CakePHP la cui clausola where coinvolga una qualsiasi tabella dipendente? Un inferno).
Senza il toArray() puoi utilizzare il lazy-load e i metodi che definisci nei model.
Per il resto, confermo: CakePHP è tremendamente meno cervellotico di Symfony.
@Jeena grazie mille, stavo in effetti cercando di capire meglio Lithium che è ancora in uno stato moooolto iniziale.
Non ho capito, ma penso di sì, se si può mixare l’uso degli array-di-CakePHP per le interrogazioni semplici e Doctrine per le interrogazioni-pesanti (tipo le many-to-many dove serve un po’ di pazienza e un po’ di codice)?!
Esattamente. La regola del pollice è: se con l’ORM di Cake riesci a fare molto agilmente la query, usa l’ORM di Cake. Se la cosa inizia a diventare un po’ più ostica, passa a Doctrine. (Io, ad essere sincera, uso Doctrine sempre e comunque: troppo più comodo!)
@Jeena a questo punto la domanda sorge spontanea: e le prestazioni? Ho visto come riempie gli array-di-risposta CakePHP. Un altro conto è Doctrine per il quale occorre un po’ di tempo in più. Sarebbe interessante eseguire un test approfondito. Chissà se avrò tempo per farlo. Ma prima devo cercare di far funzionare Doctrine su CakePHP! Grazie delle dritte!