Ha senso evitare un framework durante la creazione di una webapp di grandi dimensioni con PHP?

Essendo uno sviluppatore di applicazioni Web PHP da diversi anni, ho avuto la mia parte di MVC e framework. All'inizio ho pensato che fossero la cosa migliore dopo il pane a fette; tutto sembrava essere molto facile da implementare.

Ora, tuttavia, sembra che più complessa diventa l'applicazione, più il problema introduce il framework, quindi devo sviluppare soluzioni alternative per superarle. Tali soluzioni alternative sono in genere piuttosto scoraggianti e complesse poiché devo approfondire il codice di base del framework e apportare modifiche in modo che si comporti come voglio.

Ad esempio, in uno dei miei progetti in cui utilizzo Slim (C) + Idiorm (M) + Twig (V) (che credo sia molto flessibile), devo creare una funzione personalizzata solo per visualizzare i dati dinamici nei modelli principali; senza un framework avrei potuto semplicemente eseguire mysql_query () nel file incluso.

Va bene, i framework sono fantastici se sto creando un semplice sito Web con profilo aziendale; Posso solo montare un po 'di codice in una notte e di solito sono pronti al mattino, e la quantità di buone pratiche di programmazione e modelli di progettazione che ho imparato da loro è molto preziosa.

Ma in realtà, per un'applicazione web complessa come un sistema di gestione della scuola basato su Web all-in-one, i framework di solito ostacolano il mio processo aziendale come nell'esempio sopra.

Quindi la mia domanda è: va bene tornare alle basi e usare il codice PHP standard e le librerie per fare il mio prossimo progetto in cui potrebbero esserci un gazillion di framework e librerie, a condizione che io possa usare sufficientemente buone pratiche di codifica e seguire modelli di progettazione sensati come MVC? Il mio team di sviluppo è piuttosto piccolo: solo 2 programmatori e 1 designer. L'altro programmatore è d'accordo con i miei pensieri sopra.

La mia esperienza è praticamente l'opposto della tua. Quando si fanno cose piccole e veloci, un framework può "intromettersi" un po 'in quanto è necessario disporre il codice in un certo modo e riflettere attentamente sulle cose prima di procedere. Basta saltare direttamente a mysql_queryte per avere il tuo prototipo attivo e funzionante molto più velocemente.

Ma per siti di grandi dimensioni e complessi, disporre attentamente il codice e pensare davvero a come scrivere il codice è estremamente importante se si desidera un sito che sarà mantenibile in futuro.

In particolare, aggiungere mysql_querychiamate a parti casuali del ciclo di pagine è generalmente una pessima idea. Potresti averne uno qui e uno lì per cominciare e non è un grosso problema, ma in poco tempo avresti avuto dozzine sparse in tutto il luogo e ti stai chiedendo perché le tue pagine impiegano 3 secondi solo per il rendering. Oppure si modifica lo schema e sezioni del sito apparentemente non correlate si interrompono per motivi sconosciuti.

Secondo me un quadro dovrebbe essere usato solo se rende il processo di sviluppo più facile per te e non ingombrante. Non c'è niente di sbagliato nel non usare un framework o costruirne uno proprio, specialmente per piccoli progetti.

Ovviamente dovrai comunque prestare attenzione alla struttura e agli aspetti di sicurezza, ma considerando che stai usando i framework da molti anni probabilmente conosci già quegli aspetti al rovescio.

Per progetti più grandi, sono d'accordo con gli altri, il che significa che l'utilizzo di un framework sarà probabilmente l'opzione migliore a lungo termine.

Le mie esperienze con i "framework" lato server sono state piuttosto spiacevoli, ad esempio:

A) Jar file inferno in cui i framework sono in conflitto tra loro o con il server delle app per versioni reciprocamente incompatibili di cose che non vuoi e di cui non sai nulla e che non sono in grado di dettare comunque in quanto ti impediranno di implementare più server.

B) Esplosione catastrofica della creazione dell'oggetto più semplice in migliaia di esecuzioni SQL non necessarie.

C) La strana idea che la codifica di 100 righe di XML sia in qualche modo più semplice o più affidabile della codifica di 2 righe di Java.

D) La necessità di scrivere centinaia di righe di POJOS lato server completamente inutili per mappare su oggetti lato client in un altro, o talvolta più altre lingue (C # JS ecc.)

E) Non ho idea di cosa sia realmente accaduto quando ottieni una traccia di deep stack a 30 livelli che non include nemmeno la linea di codice che hai usato per chiamare il framework.

Sii un rinnegato, scrivi la tua struttura ... non te ne pentirai finché pianifichi prima di eliminare tutte le cose inutili che gli altri ti ingannano pensando di aver bisogno. Quindi capirai tutto, verrà spedito in Kb anziché in Mb e probabilmente "funzionerà ovunque" che era uno dei principi fondanti di Java, non è vero?

Prova a pensare in questo modo "perché ho bisogno di questo ... è solo per mantenere felice il quadro?" .. Se non ne ho bisogno, cos'altro non mi serve?

Gli sviluppatori di Django hanno presentato una presentazione che non riesco a trovare ora, ma parlano della "valle dell'efficienza" in cui un framework ti rende più produttivo.

Supponendo che tu non abbia conoscenza del framework quando avvii un progetto, la tua produttività inizialmente sarà molto bassa - imparerai la convenzione del framework piuttosto che il linguaggio della lingua (che speriamo tu già conosca).

Dopo un breve periodo di tempo, avrai preso conoscenza delle convenzioni ed è qui che i quadri brillano davvero: all'improvviso la tua produttività supera il tetto e stai progredendo e una velocità incredibile attraverso lo sviluppo.

Alla fine, tuttavia, il progetto diventerà di dimensioni tali che il framework è più un vincolo che un vantaggio, e vedrai te stesso ringhiera contro il framework per provare ad implementare alcune funzionalità.

Nella presentazione, menzionano che, naturalmente, se si conosce già le convenzioni del quadro, i progetti di dimensioni più piccole non presentano un ostacolo iniziale all'efficienza.

Pertanto, per i piccoli progetti (nella mia esperienza, qualsiasi cosa sotto ~ 500 ore) la tua efficienza con un framework sarà maggiore, probabilmente, della tua efficienza senza. Una volta che raggiungi una certa soglia (tra le 500 e le 800 ore, IME), inizi a capire che ci sono limiti a ciò che il framework può offrire.

Detto questo, i framework offrono un vantaggio molto maggiore della semplice efficienza: un framework come Symfony o Django o (presumo) Rails offre una convenzione che consente a un team di flettersi in modo dinamico e consente anche ai clienti o ai proprietari di prodotti di cambiare il proprio personale senza richiedere la nuova risorsa per riapprendere completamente un nuovo sistema: se hanno familiarità con la convenzione di un framework e se tale convenzione è stata seguita, inizialmente saranno molto più produttivi che altrimenti.

Un quadro ben progettato dovrebbe essere un aiuto per il programmatore, non un ostacolo. Se il framework che hai utilizzato ti sta ostacolando troppo, suggerirei di guardare un framework diverso. Ognuno ha il suo stile di codifica e i suoi pro e contro.

Detto questo, il framework Zend sembra essere molto popolare in questi giorni, e onestamente? Faccio fatica a capire perché a volte. Ci ho dovuto lavorare in passato e non mi è piaciuta la sua architettura. La classe Zend_Form è ridicolmente riprogettata, il suo sistema di decorazione è assolutamente orribile in uso e i decoratori legano le forme alle viste, rompendo un concetto fondamentale di OOP affermando che gli oggetti dovrebbero essere accoppiati liberamente. Ha anche un sacco di codice implementato come Singletones (che è un male per ragioni che sono ben documentate, quindi non lo ripeterò) e l'oggetto Registry contribuisce anche a incoraggiare uno stile di programmazione sciatto.

Ho sentito che Zend Framework 2 (attualmente in beta) è un prodotto molto migliore, ma il cattivo gusto che Zend 1 ha lasciato in bocca significa che non ho alcuna fretta di provarlo.

Eppure, a questo punto sto solo rantolando. :) Ci sono molti framework là fuori, ognuno con i suoi pro e contro, suggerirei di valutarne alcuni.

Ciò che descrivi è stato chiamato "complessità indotta dall'astrazione" in passato. L'unico documento sulla gestione è: Gestione della complessità indotta dall'astrazione di David Keppel. Keppel suggerirebbe che i framework abbiano un design che causa complessità indotta dall'astrazione.

Lavorare con un framework ti aiuta ad accelerare il tuo sviluppo non reinventando la ruota . Framework fornisce anche gli strumenti per aiutarti a progettare correttamente la tua applicazione (ma non ti impedisce di prendere decisioni di progettazione sbagliate, ad es. Accedere al database direttamente dalla vista).

A volte, quando è necessaria una funzionalità personalizzata, potrebbe essere necessario più tempo per scriverla correttamente. Ma se stai costantemente hackerando e trovando soluzioni alternative, stai lavorando contro il framework o il framework non soddisfa le tue esigenze.

In conclusione, l'utilizzo di un grande framework per progetti semplici (ad esempio la visualizzazione di alcuni campi da un database) può talvolta essere eccessivo. Per progetti grandi o complessi, utilizzare un framework.

Esistono più lati per scrivere il tuo codice rispetto all'uso di un Framework:

Dimensioni, conoscenze di base ed esperienza del team con cui stai lavorando : se non hanno mai usato un framework o hanno un'idea di come progettare un'applicazione, stai meglio con un framework ben documentato con molti esempi e vedi che li acceleri su.

La dimensione dell'applicazione : non si sa mai in anticipo come verrà utilizzata. Quindi è meglio essere preparati per crescere e cambiare. Il tuo framework, che vuoi codificare in una notte, può crescere con le esigenze del management? Cambia i tipi di campo nel DB e ci vuole un minuto o un giorno per implementarlo, questo è il mio punto qui.

Preparazione : se si utilizza un framework, è possibile iniziare a progettare l'applicazione anziché codificare il core dell'applicazione, utilizzarne uno in cui la sicurezza e la distribuzione sono parti importanti, questo è ciò che richiede così tanto tempo. Ogni volta.

Argomento sempre con "il management" per usare Symfony2 in quanto è un framework per lo sviluppo web. Il management pensa che sia troppo grande, costerà denaro e eviterà i programmatori poiché la curva di apprendimento è ripida.

I framework verranno ancora utilizzati per qualsiasi lingua moderna, specialmente per grandi progetti. Più un progetto diventa grande, più un framework è importante, quindi sai dove si trova la logica per ogni cosa e ogni funzione ha un layout simile. Rende più semplice la modifica di un progetto e l'apprendimento più semplice quando sai dove cercare tutti gli accessi ai dati, o tutte le presentazioni o dove sono gestite le regole aziendali.

Tuttavia, è necessario scegliere un framework adatto al progetto, una soluzione aziendale richiede un framework aziendale. Questo è il problema che incontrerai quando usi PHP. Molti (la maggior parte) dei framework non sono pensati per essere utilizzati su larga scala, ma funzionano bene per siti personali più piccoli. Per qualcosa come il sistema di gestione della scuola di cui parli, richiederà un framework più solido e potrebbe essere necessario del tempo per trovare un framework adeguato in PHP.