Strutture intelligenti per l'organizzazione delle applicazioni PHP?

10

Ci sono un milione di strutture di file system che vanno nella miriade di progetti Open Source disponibili. Cose come moduli, file di lingua, domini, librerie di terze parti, migrazioni, internazionalizzazione, backup e collegamenti di sistema ad altre parti del sistema hanno dato origine a molti approcci per organizzare il filesystem di un progetto.

Come sviluppatore di PHP mi chiedo se tra i progetti stia iniziando a emergere qualsiasi tipo di standardizzazione. Con PSR-0 abbiamo finalmente uno standard per la denominazione e il caricamento dei file, ma nulla per la mia conoscenza del resto dei componenti che compongono il sistema o di come possono essere gestiti in modo sano.

Abbiamo a che fare con molto più di un semplice MVC, quindi quali esempi ci sono di grandi progetti che gestiscono correttamente tutte queste cose?

php  project-management  code-organization  file-structure 
— Xeoncross
fonte
3
Come collega sviluppatore di PHP, non mi aspetto una sanità mentale dai componenti di PHP
— CamelBlues,
2
@CamelBlues In base alle probabilità pure del caso, alcuni sviluppatori PHP alla fine devono sbagliare e fare qualcosa di giusto.
— Xeoncross,
Non ho visto molto per quanto riguarda la standardizzazione. Fino agli ultimi anni avresti avuto le tue cartelle per le cose front-end (js, css) e poi avresti avuto inclusioni o librerie e poi modelli o temi e basta. Di recente, con i framework MVC che stanno guadagnando popolarità, non è tutto chiaro. Direi di non preoccuparti di usare uno standard per ora e di chiarire cosa succede dove si trova la tua particolare applicazione.
— Jason,

Risposte:

3

Non è davvero possibile standardizzare come dovrebbero essere strutturati i progetti, perché "dipende".

Se si introduce una struttura standard, ma in parte non pertinente ai requisiti in fase di sviluppo, è possibile ottenere un rumore aggiuntivo non necessario. Allo stesso modo, se gli standard devono funzionare per una vasta gamma di progetti, dovranno incorporare troppi scenari disparati.

Il nostro compito come sviluppatori è quello di cercare modelli e migliori pratiche e applicarli all'attività da svolgere. Usiamo la nostra esperienza e competenza per scegliere la giusta struttura di file system per il progetto a cui stiamo lavorando.

— Fenton
fonte
+1 Nel complesso sono d'accordo con te, questo è certamente un punto valido. Tuttavia, se rimuovi elementi al di fuori della lingua (cartelle di backup, script cron / build, risorse statiche, ecc.) E ti concentri solo sulla lingua stessa, non credo che lo stesso argomento possa essere fatto. Le lingue hanno già limitazioni imposte. Capire come organizzare tutte le tue classi e blocchi di codice in modo che abbiano senso per ogni progetto è un obiettivo reale e raggiungibile.
— Xeoncross
0

Non sembra esserci molto sforzo di standardizzazione in corso e, ad essere sincero, non ne vedo il vantaggio. C'è solo una regola a cui dovresti aderire, che è che non dovresti mai avere sotto il docroot cose che non appartengono a questo (una precauzione di sicurezza di base).

Oltre a questo, vorrei solo andare con ciò che ha senso per il progetto.

Se stai usando MVC (attraverso un framework o ad-hoc), allora ha senso una struttura di base con / modelli, / viste e / controller. Ma anche se non lo sei, di solito hai una sorta di livello di accesso ai dati con classi che si associano alle tue entità di dati; ha senso avere una directory per quelli; di solito hai anche un sacco di classi di business logic e funzioni di utilità, quindi un'altra directory per quelle; se si utilizza un sistema di modelli, i modelli vanno in un'altra directory; e quindi probabilmente vuoi una directory 'libraries', dove metti tutte le librerie di terze parti. (Una volta raggiunto questo punto, stai praticamente facendo MVC comunque).

Se il progetto è veramente grande, può probabilmente essere diviso in sottomoduli funzionali; se i sottomoduli sono abbastanza indipendenti, ha senso usare quelli come livello principale, con una directory aggiuntiva per il codice comune.

— tdammers
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.