Strutture di organizzazione dell'applicazione PHP intelligenti?

9

Ci sono strutture di milioni 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 syslinks ad altre parti del sistema hanno dato origine a molti approcci per organizzare il filesystem di un progetto.

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

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

    
posta Xeoncross 29.08.2011 - 21:08
fonte

3 risposte

2

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

Se si introduce una struttura standard, ma parte di essa non è pertinente ai requisiti in fase di sviluppo, si può finire con un rumore aggiuntivo che non è necessario. Allo stesso modo, se gli standard devono funzionare per una vasta gamma di progetti, dovranno incorporare troppi scenari diversi.

Il nostro lavoro come sviluppatori è cercare modelli e best practice e applicarli all'attività in mano. Usiamo la nostra esperienza e competenza per scegliere la giusta struttura del file system per il progetto su cui stiamo lavorando.

    
risposta data 12.03.2012 - 11:28
fonte
0

Non sembra esserci un grosso sforzo di standardizzazione in corso e, a essere onesti, non ne vedo il beneficio. C'è solo una regola da rispettare, ovvero non dovresti mai avere cose sotto la docroot che non ci appartengono (una precauzione di sicurezza di base).

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

Se utilizzi MVC (tramite un framework o ad-hoc), allora ha senso una struttura di base con / models, / views 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 quelli; se usi un sistema di template, i template vanno in un'altra directory; e quindi probabilmente si desidera una directory 'librerie', in cui si inseriscono tutte le librerie di terze parti. (Una volta che hai raggiunto questo punto, stai praticamente facendo MVC comunque.

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

    
risposta data 10.02.2012 - 10:36
fonte
0

Puoi seguire il layout del progetto per i due framework applicativi più popolari:

  1. Zend Framework - link
  2. Symfony - link

Questi forniranno una struttura estensibile basata sulle migliori pratiche ed esperienze degli utenti

    
risposta data 27.02.2012 - 15:41
fonte