Le risposte, molte volte, lasciano a bocca aperta. No, non perchè il contenuto sia di interesse sopraffino tale da cambiarvi la vita. Più che altro perchè mentre la leggi pensi “speriamo di non dover mai lavorare con sto qui”.

Non ho mai usato un framework, da quale dovrei iniziare?
Chi pone la domanda è già sicuramente confuso dopo le prime ricerche fatte in rete (perchè ha cercato in rete vero?). Per complicare ulteriormente le cose le risposte che riceve, tramite qualsiasi canale abbia utilizzato (mailing list, social network, sito dedicato), non fanno altro che ripetere quanto probabilmente aveva già ottenuto dalle ricerche effettuate precedentemente: risposte secche che spesso rappresentano l’unico framework conosciuto da chi risponde. Non il massimo della vita per chi brancola nel buio. Se uno volesse davvero rispondere dovrebbe quanto meno supportare la propria risposta con qualche informazione specifica riguardo almeno un paio di punti di forza che l’hanno spinto verso un prodotto piuttosto che verso un altro.

Conosco linguaggio X e linguaggio Y, per un progetto pensavo di utilizzare PHP, mi consigliate il miglior framework?
Qui la carne al fuoco è davvero troppa. Perchè oltre all’argomento framework, già sufficiente per far scoppiare il flame, si gioca anche il carico del linguaggio di programmazione in un ambiente in cui sicuramente sono presenti sviluppatori che utilizzano diversi linguaggi (più della religione). Scordatevi risposte costruttive perchè in pochi minuti arriverà la risposta “PHP? Ma sei matto? Usa Python! Al massimo Java.”. Ovviamente chi risponde aggiungerà di essere sviluppatore di lunga data e che quindi ha dalla sua l’esperienza per sparare a zero su tutte le altre cose che oggi non usa (e che magari ha provato solo per un Hello World anni e versioni prima).

Personalmente in situazioni del genere passo in punta di piedi, raso muro, facendo attenzione a non smerdarmi. Anche un consiglio pensato bene verrebbe sommerso dal resto. Tempo perso.

Framework? Ma fattelo da solo!
Sì, nel 2012, c’è ancora chi preferisce reinventare la ruota e perdere tempo a lavorare sullo strumento piuttosto che sul prodotto. Di situazioni del genere si sono stufati anche i Maya che ovviamente hanno deciso di darci un taglio, proprio quest’anno. Serve davvero che affronti i problemi legati a una scelta di questo tipo? Qualità del prodotto ottenuto dallo sviluppo interno contro quello portato avanti da un core team (già di per sè molto skillato) più gli occhi e le mani di centinaia se non migliaia di altri sviluppatori che partecipano alla causa nei più disparati modi. Documentazione per eventuali nuovi sviluppatori da introdurre sui progetti. Sicurezza, questa sconosciuta. Standardizzazione dei processi. Devo continuare? Magari in un altro post.

Meglio Zend Framework o meglio Symfony? Ed il migliore in assoluto?
Ma di cosa stiamo parlando? Migliore rispetto a cosa? Le componenti in gioco sono talmente tante, spesso nemmeno paragonabili, che non è possibile affermare “questo è meglio” in modo assoluto. Un prodotto potrà essere più interessante su una certa funzione e pagare dazio su altre. Molte funzioni, non essendo coincidenti, non possono essere paragonate perchè si finirebbe con il dire “però, effettivamente, questo serve anche per fare altro…”. Ovviamente tutto questo discorso si riferisce a prodotti di un certo livello, già affermati e che rispettano dei vincoli minimi per essere tenuti in considerazione per progetti in quel campo enterprise di cui ci piace tanto parlare. Quali sono questi vincoli? Alcuni secondo me sono i seguenti:

- documentazione
- community
- risorse disponibili (plugin, bundle, estensioni…comunque vengano chiamate)
- diffusione (per future collaborazioni, cercare nuovi sviluppatori…la diffusione di un framework fatto in casa è pari a zero)
- case history di rilievo (sapere che si può arrivare almeno fino a quel punto X aiuta)
- …

Quindi una volta appurato tutto questo una possibile risposta è “Io mi trovo bene con questo framework per questo, questo e quest’altro motivo. Ho invece avuto alcuni problemi per fare questa cosa e non mi piace molto la soluzione messa a disposizione…”.

Ok, ma tu cosa mi suggerisci allora?
Il mio consiglio è sempre quello di scremare il più possibile tra i papabili eliminando quelli che non rispettano i vincoli che il singolo sviluppatore ritiene essere più importanti per lui, il suo team, ed il tipo di progetti che affronta. Fatto ciò sporcarsi le mani ed investire qualche ora realizzando un’applicazione non proprio banale, e questo non implica il fatto che debba essere “grande”, per arrivare a prendere una decisione in base ai propri gusti ed alle proprie necessità. La decisione dopo tutto è piuttosto personale e nessuno dovrebbe sentirsi autorizzato a dire “noooo usa questo!” piuttosto che consigliare in altro modo. Quando si avrà la prima versione della risposta “io mi trovo bene con…” molto probabilmente si sarà individuato il framework più adatto allo sviluppatore/scenario in questione.

Via al flame.

Oltre alle preferenze personali c’è da valutare cosa viene offerto da ogni singolo framework e giudicare in base alle reali esigenze del progetto quale sia la soluzione migliore. Per cercare di chiarire qualche dubbio Simone Carletti ha creato una presentazione creata in occasione del Workshop di Zend Italia su Zend Framework 1.5 che consiste di una breve panoramica sull’argomento framework e web framework dedicando ampio spazio ad una comparazione tra i 3 framework PHP più utilizzati: Symfony, CakePHP e Zend Framework.

[slideshare 360643 workshopframework-1208553478186425-9]

Personalmente lo ritengo obiettivo ed un buon punto di partenza per cominciare a chiarirsi le idee a riguardo. Voi cosa ne pensate? Vi è stato d’aiuto? I commenti sono a vostra disposizione come sempre.

Il design pattern MVC identifica 3 livelli all’interno dell’architettura di un’applicazione:

• il model rappresenta l’informazione che vogliamo rappresentare e su cui l’applicazione lavora, è quella che possiamo definire business logic
• il view è come rappresentiamo il model e quindi l’informazione permettendo l’interazione da parte dell’utente
• il controller è il motore vero e proprio dell’applicazione risponde alle azioni dell’utente tramite la vista e chiede i dati al model facendo da tramite tra i due layer

L’architettura MVC separa quindi la business logic (model) e la sua presentazione (view), rendendo il codice molto più facile da mantere ed aggiornare. Tale metodologia di design delle applicazioni è rivolta principalmente a progetti di media e grande dimensione visto che richiede una minuziosa progettazione e pianificazione per essere realizzato.

CONSIGLIATI:
Understanding MVC in PHP
The MVC Pattern