Userebbe un framework PHP essere utile nel mio contesto?

Penso che in realtà stai facendo due domande, che cercherò di separare.

I reckon an advantage would be that they seem to force developers to modularise their programs using good-practice design patterns. This seems great for someone in my position. The extra functions they provide, for example: interfacing with databases in such a way as to make SQL injection impossible, would be very useful too.

La domanda riguarda concettualmente le strutture. Quello che hai detto è assolutamente vero. Alcuni framework incoraggiano l'uso di MVC che, a mio parere, è un ottimo modo per separare la logica del tuo codice e renderlo gestibile (l'abstract è migliore). Non vale la pena di collegare il tuo codice a un particolare motore di database quando puoi scrivere codice una volta, il che funzionerà con quelli più popolari.

The downside I can see is that there will be a lot of overhead for me in terms of the time taken to learn the framework itself (while still getting to grips with PHP itself). I'm also worried that it will be overkill for the scale of the apps we develop.

Questa parte riguarda specificatamente i framework per il tuo progetto. Per me è più difficile rispondere, ma certamente penso che dovresti avere un aspetto strong. Anche se hai solo un modello 1 (una tabella con i tuoi dati in), 5 controller (uno per ogni pagina di dati che vuoi manipolare) e 1 view (che prende solo i dati e li sputa come XML), I penso ancora che ne varrà la pena. Perché? Perché è una struttura comune e scalabile. Se scopri che, in pochi anni, ti ritroverai con 50 pagine XML, 50 pagine JSON e 50 pagine di testo: ti piacerebbe davvero che tu non stessi tagliando il codice XML per arrivare a json_encode , o giocherellare con strip_tags perché la tua logica di business è strettamente associata alla vista.

Inoltre, una volta che usi alcune delle funzionalità automagic se il tuo framework è simile a forme, autenticazione, ACL e simili, non vorrai annoiarti scrivendo di nuovo te stesso. Prenderà solo l'uso di uno di questi per farti capire che il tempo che passi a leggere la documentazione è gravemente superato dal fatto che hai a malapena bisogno di testare il risultato finale rispetto a se avessi scritto la funzione terra-up.

The time it takes just to configure the frameworks may not be worth it.

Quindi scegli un framework di configurazione leggero e quasi zero. Ho usato CakePHP parecchio, ma ho sentito cose buone anche su CodeIgniter. Cake, ad esempio, ha un file reale che devi modificare: database.php . Tutto il resto è facoltativo e si presenta in una modalità di debug che è possibile disattivare in seguito, una volta che si desidera distribuire l'applicazione.

The final problem I can see is that developers in the company – who have to go over my code, and who do not know the PHP framework I may use – will have a much harder time understanding it.

Non lo considererei nemmeno un ostacolo (detto che, se hai delle politiche di gestione su queste cose, dovresti - presumo che ti sia stato dato un nuovo progetto con la libertà di come vuoi avvicinarti) . Se gli sviluppatori incaricati di rivedere il codice non riescono a comprendere una semplice struttura MVC, non sono in grado di esaminare il codice. I quadri sono molto ben divisi: il codice che scrivi e il codice che ti danno sono in posizioni completamente opposte (essenzialmente). Tutto quello che stanno veramente cercando sono 3 cartelle: models , controllers e views dove dovrebbero essere in grado di esaminare ogni file e vedere se la logica è ciò che si aspetterebbero.

A lungo termine, le strutture sono la strada da percorrere. Se vuoi solo scrivere velocemente uno script che utilizzerai solo per alcuni giorni, non preoccuparti.

Il primo passo dovrebbe essere quello di consultare gli sviluppatori PHP più esperti nella tua azienda. Probabilmente usano già qualche framework, o almeno hanno un modello standard per l'organizzazione del codice. Potrebbero essere in grado di guidarti verso un framework particolarmente adatto alla tua app.

Personalmente, essendo nuovo per l'ambiente di sviluppo, non mi sentirei a mio agio nel prendere una decisione unilaterale di utilizzare un nuovo framework.

Ottima risposta di Jay, volevo indicare che c'è un'altra possibilità però.

Sembra che le cose fondamentali richieste dal framework siano standard e struttura.

Non sono anti-framework, ma non ne hai bisogno 'uno, potresti trarne beneficio.

Potresti infatti creare il tuo MVC con pochissimo codice e utilizzare un DAL comune sul back-end (probabilmente basato su PDO - bassa curva di apprendimento - o un pattern ORM / ActiveRecord).

Il vantaggio è che non avresti bisogno di imparare un framework, né uno qualsiasi dei tuoi colleghi, ma impareresti come progettare uno semplice! Un sacco di esempi su Google. Questo potrebbe essere un buon esercizio per te, in quanto richiede di capire il MVC (che in effetti è estremamente semplice nel concetto), che a sua volta ti aiuterà a capire i benefici, come li hai pensati dettagliatamente.

La scelta del percorso sopra può consentire di conservare più risorse esistenti in quanto è possibile considerare i requisiti di migrazione.

Framework IMHO si rivela davvero utile quando si cerca di mantenere standard comuni tra i team e di risparmiare la creazione di funzionalità comuni complesse soggette a errori. Possono essere restrittivi soprattutto durante la migrazione di un sistema esistente. Quindi potresti prendere questa decisione in base alla complessità futura percepita della tua applicazione, se rimane semplice non hai bisogno di un framework, se cresce, potresti desiderare di averne usato uno fin dall'inizio.

Per mantenere l'apprendimento più piccolo, prova ad imparare CodeIgniter (se hai un programma molto ristretto di tempo per imparare, scegli CodeIgniter) e / o anche a limitare il refactoring del codice alla corretta orientazione degli oggetti e una buona struttura di classe. Non direi che la tua applicazione sarà magicamente più controllabile da un framework.

Non so come o se usi tecniche orientate agli oggetti ma non dovrebbe essere sufficiente? Mantenere la logica del database (recupero / inserimento / aggiornamento) in una classe separata (-es) (= Modello). Queste potrebbero essere operazioni "di base" per l'accesso ai dati.

Una classe più rifinita sarebbe tutti i dati che la pagina specifica deve avere, combinando diverse classi di modelli a un rendering specifico della vista. Comunque dovrebbe usare solo il codice, non l'html !. (= viewmodel).

E avere ciascuna "pagina" in un file separato (vista), gestita da uno specifico "viewmodel" per tutti i dati.

Questo tipo di comportamento è chiamato MVVM - model-view-viewmodel - (http://en.wikipedia.org/wiki/Model_View_ViewModel).

Questi sono piccoli passi che miglioreranno significativamente il tuo sito se non li usi già.