Il miglior framework per il Web

lunedì 14 novembre 2011 - 11:00

di Alessandro Nadalin

No, non faremo l’errore grossolano di sbilanciarci, sarebbe incoerente e incorretto: non esiste un framework migliore, ma ne esistono di più adatti alle esigenze di ogni progetto.

Constatato cià è quindi possibile elencare i desiderata tecnici che vorremmo in ogni prodotto, per poter lasciarvi lo spunto di tracciare una matrice e trarne le vostre personali conclusioni.

Sicuramente la separazione delle responsabilità , all’interno del prodotto, è necessaria: che lo si voglia chiamare Model2 o MVC, questo pattern è forse alla base di ogni framework per il Web ben strutturato: un punto di vantaggio lo si ha, forse, quando ci viene permesso di pluggare il modeling in maniera abbastanza trasparente (a là  Symfony2).

Un buon prodotto dovrebbe peraltro permettere, attraverso un IoC container o simili, di gestire le dipendenze all’interno dell’applicazione in maniera pulita, trasparente, altamente configurabile e pluggabile: è quindi sempre bene ottenere i “servizi”, piuttosto che gestirne istanziazione e ciclo di vita a mano, considerazione alquanto banale ma solo recentemente arrivata, per esempio, al mondo PHP.

Un ulteriore plus è sicuramente offerto dalla possibilità  di dispatchare compiti solitamente assolti dal framework a componenti esterni, non gestiti nemmeno dall’applicativo che costruiamo: ne è un esempio la spinta che personalità  come Ryan Tomayko, nel panorama di Rails, danno alla cache HTTP rispetto a quella gestita all’application-level.

L’ultimo punto che vogliamo citare qui, è la forte posizione che gli strumenti di testing hanno all’interno del prodotto: senza di essi è difficile controllare regressioni all’interno dei nostri applicativi, esponendoci, di fatto, a fallimenti/bugs molto più probabili.

Non è una lista completa, nemmeno forse esaustiva, sicuramente quanto basta per iniziare a farsi qualche domanda.

Categoria: Software e Servizi | Commenta

Commenti per Il miglior framework per il Web

apprezzo il post per il tentativo solo in parte riuscito di spostare l’argomento dal solito il “il mio é meglio del tuo” a ragioniamo di cosa serve veramente nei progetti su cui si lavora realmente.

quelli che proponi però sono requirements costruiti su misura per symfony e li trovo “alla moda”.
essite da 2 giorni http caching? come mai salta fuori solo dopo che Fabien lo ha divulgato in qualche conferenza? e in quali siti lo impiegheremmo? con quali carichi? con quali server?
Per i miei lavori, con carichi modesti in relazione a infrastrutture moderne, il problema non si pone.
… senza offesa, non perdere di vista che il mondo é grande ;)

ti elenco i miei requirements, il mio focus é sulla produttività :

1) leggero: nel senso che deve fare pochissime cose e prevedere componenti aggiuntivi per tutto il resto. fatti i dovuti sacrifici in questo senso, le prestazioni diventano un problema secondario
2) semplicità : deve essere abbastanza semplice da non farmi perdere tempo nel tentativo di comprendere la sua struttura e le sue ineluttabili bizzarrie. anche documentazione e comunity contribuiscono ad alleviare il problema, ma di base una soluzione semplice non ha bisogno di molto sostegno per divenire produttiva
4) strumenti di prototipizzazione rapida, tipo admin generator e view helpers, nota che questo punto é economicamente più importante di altre considerazioni, di tenore un po’ astratto e accademico, che non contribuiscono a terminare i progetti e fatturare. su questo punto le soluzioni disponibili sono largamente insufficienti e anche per questo molti colleghi usano i CMS().
3) testato e testabile. insomma deve funzionare. in questo senso DIC viene in aiuto ma non é l’unica strada

personalmente apprezzo il nuovo symfony perché molto orientato al punto 1, leggerezza e interoperabilità , apprezzo il vecchio symfony 1.4 per il punto 4, prototipizzazione. nessuno dei due però é orientato alla semplicità  e alla produttività  anzi forse si preoccupano di piacere ad ambiti enterprise o comunque di vasta scala.

non temere arriverà  prima o poi symfony 3 a dimostrare che il 2 non era poi così vicino alla perfezione

# - Postato da devsmt 14 novembre 2011 alle 11:58

Secondo me non ha più senso parlare di Framework, ma di “ecosistema”. Nell’ambiente ruby/rails ci sono tante gem che si occupano delle stesse cose ma con granularità  e specificità  diversa.
Perché é giusto dare un framework che funzioni out-of-the-box e ci sia una struttura di base, ma é inevitabile che per funzionare con diversi componenti dbms, nosql, .. alcune parti del framework debbano poter essere sostituibili e non si può fare un’astrazione che funzioni per tutto.

# - Postato da grigio 15 novembre 2011 alle 10:15

Non sono mai riuscito a utilizzare un framework, sempre scritto tutto a mano. Riciclando codice dove potevo. Li trovo limitanti e con i clienti si rischia sempre di avere le mani legate alle loro richiesta allucinanti.

# - Postato da JohnnyBeGood 15 novembre 2011 alle 20:09

Nel 2008 avevo sentito parlare di CakePhp, ma lo ignorai, sempre in quell’anno fui in canada per alcuni mesi e comprai un libro (in inglese) Sviluppare web 2.0… In sostanza era un libro incentrato tutto su Zend… d’oh… Poi un giorno, per lavoro, premetto che odio le cose già  fatte anche io e quindi tutti quelli che sono CMS per una modificabilità  poco elastica a primo impatto, mi sono imbattuto su CakePhp. Ad oggi ho imparato parecchio sui vari componenti, sono in grado di estendere componenti aggiuntivi, helpers e qualsivoglia cosa. Avevo visto anche Symphony, ma inizialmente il tutorial in 5 minuti di cake é di grande impatto rispetto a Symphony. Ciò non toglie che mi sto addentrando anche dentro altri framework e devo ammettere che li sto apprezzando davvero molto!

# - Postato da Giorgione 24 novembre 2011 alle 18:42

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

È possibile utilizzare questi tag ed attributi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>