Impegno a Zend Framework: nessun argomento contro?

Sto ristrutturando un CMS di grandi size su cui sto lavorando da un certo numero di anni. Il prodotto stesso è ottimo, ma alcuni componenti, il Database e le classi di traduzione, per esempio, necessitano di una sostituzione urgente – in parte auto-fatti nel lontano 2002, cresciuti in un po 'di caos nel tempo e potrebbero avere problemi a sopravvivere ad un controllo di sicurezza .

Quindi, ho osservato da vicino una serie di framework (o, più esattamente, librerie di componenti, poiché non intendo modificare la struttura di base del CMS) e ho finito col gradire Zend Framework come migliore. Offrono un solido model MVC ma non ti costringono a farlo e offrono molti componenti professionali che hanno ovviamente ricevuto molta attenzione (lo sapevi che ci sono più plurali in russo e non puoi tradurli usando un semplice ($number == 0) or ($number > 1) interruttore? Non l'ho fatto, ma Zend_Translate è in grado di gestirlo. Giusto per illustrare il livello di torpore con cui la libreria sembra essere stata costruita.)

Ora sono letteralmente sul punto di non return, iniziando a sostituire i componenti chiave del sistema con quelli prodotti da Zend. Non ho davvero ripensamenti – e sicuramente non sto cercando di incitare una guerra di fuoco – ma prima di andare avanti, vorrei fare un passo indietro per un momento e verificare se c'è qualcosa che parla contro bind strettamente un grande sistema a Zend Struttura.

Cosa mi piace di Zend:

  • Per quanto posso vedere, codice di altissima qualità
  • Estremamente ben documentato, alless per quanto riguarda le introduzioni su come funzionano le cose (non ho ancora dovuto usare la documentazione dettagliata dell'API)
  • Sostenuto da una società che ha interesse nel vedere prosperare la struttura
  • Ben accolto nella comunità, ha una notevole base di utenti
  • Utilizza standard di codifica che mi piacciono
  • Viene fornito con una serie completa di test unitari
  • Mi sembra la scelta giusta da fare – o alless, una delle scelte giuste – in termini di sviluppo moderno e professionale del PHP.

Ho pensato di incapsulare e astrarre le funzionalità di ZF nelle proprie classi per essere in grado di cambiare i framework più facilmente, ma sono giunto alla conclusione che questa non sarebbe stata una buona idea perché:

  • sarebbe un livello non necessario di astrazione
  • potrebbe costare performance
  • il grande vantaggio dell'utilizzo di un framework – l'esistenza di una base di sviluppatori che ha familiarità con i suoi componenti – verrebbe in parte annullato

pertanto, l'impegno per ZF sarebbe profondo. Quindi la mia domanda:

C'è qualcosa di sostanziale che parla contro l'impegno nel Zend Framework?

Hai una conoscenza privilegiata dei piani di Zend Inc. per andare male nel 2011 e renderla una libreria a codice chiuso? Zend Inc. è gestita da vampiri gestiti da vampiri malvagi che vogliono conquistare la terra? (Nei commenti è stato stabilito che Zend è in realtà gestito da vampiri.) Ci sono dei difetti concettuali nella base di codice che si iniziano a notare quando si è passati a tutti i progetti? L'apparenza del codice qualità è un'illusione? Il codice sembra buono, ma funziona terribilmente lento su qualcosa sotto la mia workstation quad-core?

Accettare la risposta

Grazie mille a tutti per il vostro feedback dettagliato. Vorrei poter creare una taglia e distribuirla equamente tra tutti i rispondenti.

Tra molte opinioni favorevoli alla ZF, ce n'era una molto ben fondata contro. L'ho presa molto sul serio e ho dato un'occhiata alle alternative, principalmente Yii e Kohana. Da quel confronto e dalla lettura di alcune altre opinioni riguardanti ZF e prodotti concorrenti, posso vedere che Zend può essere visto come gonfiato in alcuni campi rispetto a frameworks più minimalistici. (Posso anche vedere che questo "gonfio" è per lo più con buone ragioni per fornire la massima flessibilità, ma la domanda se si desidera la massima flessibilità e affrontare la conseguente complessità, o un approccio più semplice con linee guida chiare, è valida.)

Ad each modo, andrò a cercare Zend per il progetto, perché l'uso principale che ho per il framework è come una libreria di componenti . Non voglio adottare il model MVC di Zend, ho solo bisogno di componenti di alta qualità per l'internazionalizzazione, la gestione delle sessioni e così via. Poiché sto creando un prodotto ridistribuibile, la flessibilità di Zend (ad esempio il supporto per cinque diversi formati di dictionary) è la benvenuta. Inoltre, ZF sembra essere l'unica struttura che consente il grado di libertà che voglio (nessun uso forzato di schemi, strutture di file …) per quanto posso vedere, nessun'altra struttura offre questo.

Per i progetti futuri in cui voglio utilizzare le effettive funzionalità MVC e totalmente sottomesso alle convenzioni di un framework per la creazione di applicazioni, la denominazione, lo stile e le procedure, potrei non andare necessariamente per Zend, ma per un approccio più minimalist quadro come Yii o Kohana.

Zend Framework è la scelta migliore . Migliore API di framework di tutti, codice leggibile, convenzioni linguistiche, buoni documenti, comunità, supporto e tutto
Le mie antipatie (soggettive, le persone mabe mi faranno perdere tempo per questo) sono:

  • Zend_Form , ha il suo uso, ma in generale è troppo invadente, voglio solo strutturare il mio HTML non combattere API e decoratori.
  • Zend_Db_Table , potente, ma ha bisogno di molto lavoro per raggiungere i tuoi obiettivi, e Rails mi ha insegnato a essere pigro. No, non voglio scrivere 3 classi per un model, una per il tavolo, una per il set di righe, una per la row, quindi legarle l'una all'altra e così via. Potrei aver bisogno del gateway dati della tabella a un certo punto, ma per ora voglio davvero interfacere questi dati con un record attivo veloce.
  • nessuna logging triggers. Con il ritardo del binding statico in php 5.3 questo potrebbe cambiare …

Ho provato davvero a usare questi due per un paio di mesi finché non ce l'ho fatta.

Li ho superati (idee da Ruby on Rails)

  • usa i helper di visualizzazione semplice invece di Zend_Form come in:
    echo $this->formText('email', '[email protected]', arrays('size' => 32));
  • avere i miei templates Active Record come ( http://www.phpactiverecord.org )
  • validationre e filtrare sul model
  • per i casi di angolo davvero estremi, si può ricorrere a Zend_Form + Zend_Db_Table, anche se non ne ho mai sentito il bisogno.

MODIFICARE
Ci sono alcuni nuovi bambini che vale la pena dare un'occhiata, come Laravel

L'unica cosa che ZF vince davvero su altri framework è il router, controller e viste, convenzioni, codice pulito e leggibile, process.

A less che tu non stia aspettando un gigantesco progetto gigante con più di 20 sviluppatori, io, se fossi in te, farei qualsiasi cosa, incluso il sacrificare un arm e / o una gamba solo per evitare Zend Framework .

  • La bella opzione che hai scoperto potrebbe sembrare comoda – al punto in cui trovi altre impostazioni di 1k + che sembrano solo una perdita di tempo e uno sforzo di sviluppo nella libreria. Ti troverai presto nel mezzo di Customization Ocean, sopraffatto da impostazioni, interfacce e classi astratte.
  • La documentazione non è solo dettagliata, ma di conseguenza molto lunga e complicata (in modo simile alla biblioteca stessa). Voglio lezioni di 3a parte per aiutarmi e non per intromettermi.
  • Il fattore più importnte è stata la velocità di sviluppo per me, ovviamente. Senza un gruppo di college attorno a te, Zend Framework dovrebbe essere seriamente considerato se essere abbandonato.
  • Ci sono troppe persone che fanno i desideri nel tracker dei problemi di Zend, troppe persone che implementano il codice. Ad oggi, devo ancora vedere una visione seria dietro quei milioni di linee.

I miei due centesimi arrivano davvero a un certo punto: nonostante (o meglio, a causa di?) È supportto dall'azienda PHP, è troppo gonfio per l'uso personale e per progetti di piccole e medie size.

Il mio team sta attualmente utilizzando Yii per un progetto di medie size. Non è neanche perfetto, ma è molto più utilizzabile e adatto agli sviluppatori rispetto al fratello maggiore.

Non ho grandi argomenti contro ZF – al contrario; ovviamente, non ho ancora usato tutti i componenti (non è sicuro che qualcuno lo abbia mai fatto ) , ma non ho mai visto nulla di così "cattivo" quando ho consultato le fonti.

Quando inizio un nuovo progetto, in genere andrei con Zend Framework, in realtà, se io sono colui che deve scegliere …

C'è alless un argomento che vorrei aggiungere alla tua list:

  • Zend Framework può essere integrato con altri componenti: hai parlato di utilizzare componenti di ZF nella tua applicazione, ma non hai parlato del contrario.
    • Un ottimo esempio è Doctrine (l'ORM predefinito di Symfony) , che può essere usato con ZF abbastanza facilmente – ed è molto meglio di Zend_Db , secondo me!

Oltre a ciò, devo dire che sono d'accordo con tutti i vostri punti.

Riguardo all'incapsulamento delle classi ZF nelle tue classi: sì, potresti farlo (a volte lo faccio) , ma non consiglierei di farlo per tutto: nella maggior parte dei casi, probabilmente non sarà necessario.

A proposito del futuro :

  • Zend Framework è rilasciato sotto una licenza BSD, il che significa che ciò che esiste non può essere chiuso.
  • Chiuderlo significherebbe la sua fine, comunque – sarebbe una mossa stupida, nel context della comunità PHP
  • Il lavoro su ZF 2.0 è appena iniziato (con PHP 5.3 come requisito, btw)
    • Forse, a seconda del tuo programma per la tua applicazione, potrebbe essere interessante?
    • Alless se non hai bisogno di iniziare a sviluppare prima di alless un paio di mesi …

Stiamo sviluppando con ZF da quasi un anno ormai, e non ho davvero nessun problema con esso. Ho avuto un po 'di curva di apprendimento, ma una volta capito, mi sono reso conto di quanto sia ben fatto questo framework.

Rispetto ad altri framework, alcune persone potrebbero sottolineare l'assenza di una libreria Model come svantaggio. In realtà preferisco non sapere cosa usare e l'integrazione di Doctrine con ZF è semplice. Se stai sviluppando in PHP 5.3 e vuoi un ORM, consiglio vivamente Doctrine 2 (avvertenza: è ancora in fase di test alfa).

L'altra cosa grande è essere in grado di scegliere e scegliere quello che vuoi o non vuoi. Non sono un grande fan di Zend_Form, ma non devo usarlo se non lo voglio. Inoltre, c'è un'architettura di plugin molto liberamente strutturata che ti permette di agganciare facilmente le tue librerie nel framework.

Quindi, ne sono un grande fan.

Una cosa che mi manca in Zend Framework è un corretto mappatore OR. Zend_DB è ok ma presenta alcune carenze, soprattutto quando si tratta di enormi database (molte tabelle) che diventano molto macchinosi. Ma ci sono un paio di mappatori OR là fuori che possono essere integrati (es. Zend-framework-orm o Doctrine come menzionato da Pascal MARTIN).

Ma sì, Zend è eccellente, molto potente e ritengo che sia in qualche modo ciò che in realtà dovrebbe essere / dovrebbe essere il PHP in termini di interface e funzionalità.

Ciò che mi piace particolarmente oltre all'ovvio è il supporto per Dojo per le applicazioni rich client e il supporto SOAP .

Ho usato ZF su un progetto come unico sviluppatore. Sebbene la curva di apprendimento fosse piuttosto ripida, non ho incontrato troppi problemi descritti sopra. In generale, ho trovato il framework molto flessibile e l'accoppiamento libero dei componenti ha reso facile fare le mie cose quando il modo ZF di farlo non soddisfaceva le mie esigenze.

Ma avendo recentemente iniziato a usare python, direi che uso python;)