Ha senso evitare un framework quando si costruisce una webapp di grandi dimensioni con PHP?

La mia esperienza è praticamente l'opposto della tua. Quando si fanno cose piccole e veloci, un framework può "intromettersi" un po 'quando è necessario disporre il codice in un certo modo e pensare attentamente alle cose prima di procedere. Salendo direttamente a mysql_query puoi far funzionare il tuo prototipo molto più rapidamente.

Ma per siti di grandi dimensioni e complessi, l'elaborazione accurata del codice e davvero pensare a come scrivi il tuo codice è estremamente importante se vuoi che un sito sia mantenibile in avanti.

In particolare, aggiungere mysql_query di chiamate a parti casuali del ciclo di pagina è generalmente una pessima idea. Potresti averne uno qui e uno lì per cominciare e non è un grosso problema, ma tra poco ne avresti sparsi in tutto il luogo e ti stai chiedendo perché le tue pagine impiegano 3 secondi solo per renderizzare. Oppure modifichi lo schema e le sezioni apparentemente non correlate dell'interruzione del sito per motivi sconosciuti.

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

Ovviamente avrai ancora bisogno di prestare attenzione alla struttura e agli aspetti di sicurezza, ma considerando che hai utilizzato i framework per molti anni probabilmente già conosci questi aspetti.

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) Il file Jar è un inferno in cui i framework sono in conflitto tra loro o il server delle app per versioni reciprocamente incompatibili di cose che non vuoi e di cui non sai nulla e non sono in grado di dettare comunque in quanto ti impediranno di dalla distribuzione su più server.

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

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

D) La necessità di scrivere 100s di linee di POJOS lato server completamente inutili per mappare su oggetti lato client in un altro, oa volte in più lingue (C # JS ecc.)

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

Sii un rinnegato, scrivi la tua struttura ... non te ne pentirai se pianifichi prima di eliminare tutte le cose inutili che gli altri ti ingannano nel pensare di aver bisogno. Allora capirai tutto, verrà spedito in Kb invece che in Mb e probabilmente sarà "eseguito ovunque" che era uno dei principi fondanti di Java vero?

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

C'è stata una presentazione degli sviluppatori di Django, che ho difficoltà a trovare adesso, ma parlano della "valle dell'efficienza" in cui un quadro ti rende più produttivo.

Supponendo che tu non abbia alcuna conoscenza del framework quando inizi un progetto, la tua produttività inizialmente sarà molto bassa - imparerai la convenzione del framework piuttosto che l'idioma del linguaggio (che si spera che tu già sappia).

Dopo un breve periodo di tempo, avrai raccolto le convenzioni e questo è il punto in cui le strutture brillano davvero - improvvisamente la tua produttività è al massimo e stai progredendo e incredibilmente veloce nello sviluppo.

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

Nella presentazione, menzionano che, naturalmente, se hai già conoscenza delle convenzioni del framework, i progetti di dimensioni minori non hanno l'ostacolo iniziale all'efficienza.

Quindi, per piccoli progetti (nella mia esperienza, qualsiasi cosa al di sotto di ~ 500 ore) la tua efficienza con un framework sarà maggiore, probabilmente, rispetto alla tua efficienza senza. Una volta raggiunta una certa soglia (tra 500 e 800 ore, IME), inizi a capire che esistono limitazioni a ciò che il framework può offrire.

Detto questo, le strutture offrono un vantaggio molto maggiore rispetto alla sola efficienza - una struttura come Symfony o Django o (presumo) Rails fornisce una convenzione che consente a un team di flettersi dinamicamente e consente anche ai clienti o ai proprietari di prodotti di cambiare la propria personale senza richiedere alla nuova risorsa di reimparare completamente un nuovo sistema - se hanno familiarità con la convenzione di un framework e che tale convenzione è stata seguita, inizialmente saranno molto più produttivi che in altro modo.

Una struttura ben progettata dovrebbe essere un aiuto per il programmatore, non un ostacolo. Se la struttura che hai usato ti sta intromettendo troppo, ti suggerirei di guardare a un quadro 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. Ho dovuto lavorare con esso in passato e non mi è piaciuta la sua architettura un po '. La classe Zend_Form è ridicolmente sovrastampata, il suo sistema decoratore è completamente orrido in uso, ei decoratori legano le forme alle viste, infrangendo un concetto fondamentale di OOP che afferma che gli oggetti dovrebbero essere liberamente accoppiati. Ha anche un sacco di codice implementato come Singletones (che sono cattivi per ragioni ben documentate, quindi non lo ribadisco) e l'oggetto Registry contribuisce anche a incoraggiare uno stile di codifica sciatto.

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

Eppure, a questo punto sto solo sbraitando. :) Ci sono un sacco di quadri là fuori, ognuno con i loro pro e contro, suggerirei di valutarne alcuni.

Ciò che descrivi è stato definito "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 hanno un design che causa complessità indotta dall'astrazione.

Lavorare con un framework ti aiuta a velocizzare lo sviluppo con non reinventare la ruota . Framework fornisce anche gli strumenti per aiutarti a progettare correttamente la tua applicazione (ma non ti impedisce di prendere decisioni di progettazione inadeguate, ad esempio accedere al database direttamente dalla vista).

A volte quando hai bisogno di una funzionalità personalizzata potrebbe essere necessario più tempo per scriverlo correttamente. Ma se continui a hackerare e trovare soluzioni alternative, stai lavorando contro il framework o il framework non soddisfa le tue esigenze.

La linea di fondo è questa, usare un grande framework per progetti semplici (ad esempio la visualizzazione di alcuni campi da un database) può a volte essere eccessivo. Per progetti grandi o complessi, usa un framework.

Ci sono più lati per scrivere il tuo codice e usare un Framework:

Le dimensioni, le conoscenze di base e l'esperienza del team con cui lavori : se non hanno mai utilizzato un framework o non hanno idea di come progettare un'applicazione, è meglio con un framework ben documentato con un sacco di esempi e vedi che li acceleri.

La dimensione dell'applicazione : tu mai sai in anticipo come verrà utilizzato. Quindi è meglio essere preparati per crescere e cambiare. Il tuo framework, che vuoi codificare in una sola notte, cresce con le esigenze della gestione? Cambia tipo di campo nel DB e ci vuole un minuto o un giorno per implementare, questo è il mio punto qui.

The Preparation : se usi un framework puoi iniziare a progettare l'applicazione invece di codificare il nucleo della tua applicazione, usane uno dove security e deployment sono parti importanti, questo è quello che ci vuole così tanto tempo. Ogni volta.

Ho sempre argomentato con "la gestione" per usare Symfony2 poiché è un framework per lo sviluppo web. Il management pensa che sia troppo grande, costerà denaro e farà intimidire i programmatori mentre la curva di apprendimento è ripida.

I quadri continueranno a essere utilizzati per qualsiasi lingua in moderno, in particolare per i progetti di grandi dimensioni. Più grande è il progetto, più importante è un framework, quindi sai dove si trova la logica per ogni cosa e ogni funzionalità ha un layout simile. Rende più semplice la modifica di un progetto e apprende più facilmente quando sai dove cercare tutti gli accessi ai dati, o tutte le presentazioni o dove sono gestite le regole aziendali.

Però è necessario scegliere un framework che si adatti al progetto, una soluzione enterprise richiede un framework capace di impresa. Questo è il problema che stai per incontrare quando usi PHP. Molti (molti) framework non sono pensati per essere usati su larga scala, ma funzionano bene per siti personali più piccoli. Per qualcosa come il sistema di gestione scolastica che hai citato, richiederà un framework più robusto e potrebbe essere necessario del tempo per trovare un framework adeguato in PHP.