Sto costruendo un'applicazione attualmente in PHP e sto cercando di decidere se utilizzare un framework preesistente come il codeigniter o creare il mio framework. L'applicazione deve essere davvero scalabile e voglio avere il pieno controllo di ciò che mi fa pensare che dovrei costruirmi una mia, ma allo stesso tempo non voglio reinventare la ruota se non dovessi farlo.framework php - build your own vs pre-made
Qualsiasi consiglio molto apprezzato.
Grazie
Utilizzare un quadro esistente.
Prima di tutto creare un framework da zero rappresenta un enorme investimento in termini di tempo e impegno. Il processo richiede molte prove ed errori, perché stai progettando qualcosa che deve essere sia semplice che potente. Per ogni decisione progettuale dovrete chiedervi come influirà su ogni singolo progetto futuro che sarà costruito sulla vostra struttura.
Penseresti che potresti prendere ogni decisione di progettazione e ponderarla rispetto ai requisiti che avresti per qualsiasi altro progetto software, ma il fatto è che non conosci le tue esigenze. Non puoi conoscerli, perché un framework dovrebbe essere in grado di fare quasi tutto (o avere la possibilità di essere esteso per fare quasi tutto) nel suo dominio. Il futuro progetto a dovrà essere in grado di fare x. Il tuo framework può permetterlo senza trasformarlo in codice spaghetti? E se il progetto b dovesse fare y? Cosa succede se il progetto c ha bisogno di fare z?
Hai previsto tutto?
Ora la normale risposta a questo è che se qualcosa non funziona, lo cambierete solo in futuro. È software, dopo tutto. Tuttavia, un framework non è come una semplice applicazione. Dovrebbe avere un'interfaccia e una volta esposta al software che la utilizzerà, non è possibile cambiarla. Puoi estenderlo, ma non cambiarlo. Quindi ora devi pensare ai metodi deprecating, alle versioni api e alla compatibilità delle versioni. È una serie di problemi completamente nuova da affrontare insieme alla normale manutenzione del framework e alla scrittura di nuove applicazioni.
Poi c'è la documentazione.Hai bisogno di un'API, tutorial, codice di esempio. Una volta che hai costruito il tuo framework, devi occuparti anche di questo. Potresti ignorarlo, ma ti assicuro che alla fine tu stesso dovrai scoprire che metodo hai scritto 6 mesi fa. Cosa restituisce? Cosa succede se si verifica un caso speciale x? Hai scritto tutto questo o hai bisogno di rivedere il codice? E non dirò nemmeno quanto sarà facile per un nuovo membro del team iniziare su una struttura personalizzata la cui documentazione si trova completamente o almeno nella tua testa.
Devi anche riconoscere che, a meno che tu non stia lavorando con i migliori e più brillanti (e abbia un budget da abbinare), non avrai mai l'ampio set di librerie vantate dai framework esistenti. È possibile analizzare, progettare, codificare, testare e eseguire il debug più velocemente di una comunità open source?
Infine dovresti chiederti se sei abbastanza bravo da scrivere un quadro. Ti sei immerso profondamente nel codice di un moderno framework OO PHP5 per scoprire cosa lo rende interessante? E, soprattutto, conosci lo perché lo fa le cose in modo particolare? Tieni presente che qualsiasi errore che fai nel tuo progetto può esplodere nei tuoi mesi da ora in poi e puoi finire per pagare per loro più e più volte.
Per riassumere, consiglierei di seguire un quadro esistente; non significa però che devi sceglierne uno e come questo. Prenditi il tempo che altrimenti dedicheresti allo sviluppo di un nuovo quadro e dedicandolo all'apprendimento di uno esistente. Quindi puoi estenderlo per soddisfare le tue esigenze. Ricorda anche che potrebbero esserci cose che non sarai in grado di fare. Ma ti assicuro che ci sarebbero cose che non potresti nemmeno fare con il tuo framework, quindi non importa molto. Un quadro impone alcune limitazioni. È il prezzo che si paga per essere in grado di sviluppare applicazioni più velocemente.
La risposta breve è Symfony2 IHMO.
Le ragioni sono:
Ovviamente i punti precedenti sono validi per un set molto piccolo di strutture professionali! Il mio preferito è symfony2, ma ci sono un certo numero di buone alternative.
Creare un elenco di requisiti per il framework (ORM, PHP 5.3, PDO, ecc.). Quindi scorrere le strutture esistenti e restringerle per trovare quelle corrispondenti alle proprie esigenze. Quindi guarda la base di codice, la documentazione, la comunità, l'attività del progetto: senti qualcosa con cui ti piacerebbe lavorare? Sii anche realistico sul tempo necessario per implementare tutte le tue esigenze da solo: vuoi concentrarti sulla costruzione di un'applicazione o di un framework?
La decisione è molto semplice e semplice. Se vuoi imparare e avere il pieno controllo - vai per il tuo
Se vuoi solo fare soldi velocemente - vai per uno pronto.
Mentre in passato ho creato il mio framework CMS e utilizzato framework php personalizzati (interni), troverei un framework attivo che si adattasse al vostro stile di sviluppo e lo usasse.
A meno che il prodotto/applicazione principale sia il framework. Ma non sembra così.
Le preoccupazioni relative al controllo e alla scalabilità devono essere applicate all'host di framework disponibili, fornendo un breve elenco di opzioni adatte alle proprie esigenze.
Certo, non è una questione di 'in-house' VRS 'pubblico', poi una volta che hai fatto quella chiamata basta scegliere qualsiasi quadro vecchio.
di rispondere alla domanda dietro la questione, di un quadro che offre un controllo completo e dovrebbe essere in grado di scalare ragionevole bene (io non sono sicuro di come è necessario il quadro in scala), vorrei suggerire Zend Framework. È possibile utilizzare singole parti di esso, riscrivere ciò che si desidera ed è molto più di una semplice implementazione MVC.
Aggiornamento: un rapido esempio di personalizzazione con Zend. Se non vuoi utilizzare il loro stack MVC, ma hai bisogno di qualcosa per instradare le richieste, puoi semplicemente utilizzare la libreria del router di Zend. Se ti piace lo stack MVC, ma odi il modo in cui funziona il router, puoi semplicemente implementare l'interfaccia e scrivere il tuo router.
Questo vale anche all'esterno dello stack MVC. Zend ha un sacco di librerie per posta, feed RSS, cache, auth, db, ecc. Usa quello che vuoi e ignora il resto. Estendi ciò che desideri, la maggior parte del framework è suddivisa in livelli con interfacce/classi astratte/generalizzate che puoi costruire se la funzionalità standard non soddisfa le tue esigenze.
Lavoro in un'azienda che inizialmente ha scritto il proprio framework, costruito da un ragazzo che ha lavorato qui. Era usato solo su un progetto. La ragione di ciò è che presto ci siamo resi conto che sebbene fosse intelligente e molto buono, non esisteva documentazione per questo. Quindi se impieghiamo un altro sviluppatore o un ragazzo freelance, dovrebbero impararlo.
Corriamo con CakePHP per un po ', che è popolare, ma sembra un disastro. Alla fine abbiamo optato per KohanaPHP. Facile da estendere, una buona documentazione (probabilmente non lassù con altri), codice ben formattato (nel senso che se non riesci a trovare la documentazione puoi rapidamente capire cosa sta succedendo). Il modo in cui è scritto il framework rende abbastanza facile per uno sviluppatore raccogliere e seguire ciò che sta accadendo. Considerando che abbiamo sempre avuto problemi a farlo con CakePHP.
Penso che l'unico argomento per far ruotare il proprio framework sia che si desideri qualcosa di altamente personalizzato. Ma Kohana è così facile da estendere, puoi semplicemente buttarlo lì dentro. Non devi usare le loro librerie impacchettate se davvero non vuoi.
Detto questo, alcuni progetti non mi preoccupano affatto di un framework, solo una sorta di soluzione di routing, come GluePHP. Dal momento che sarebbe eccessivo usare un framework stack completo.
Se stavi solo cercando di esercitarti, ti suggerirei di scriverne uno tuo. Altrimenti, comunque, andremo sicuramente con l'uso di uno esistente. Symfony ftw.
Sto costruendo da solo e sono molto contento di averlo fatto in termini di apprendimento, che per me è importante. Anch'io amo avere il controllo totale del mio codice. Viene fornito con molti negativi, il più grande è che sono l'unico che sa come usarlo. Inoltre, viene dedicato molto tempo allo sviluppo per migliorare il mio framework piuttosto che fornire prodotti ai miei clienti. Ma non posso sottolineare abbastanza che mi piace davvero tanto costruire e usarlo.
Se vuoi imparare (MOLTO) costruisci il tuo. Se vuoi solo portare a termine il lavoro, usa uno esistente. (Prima di iniziare da solo sono quasi andato con CodeIgniter)