PHP Zend Framework - Zend_Config e stato globale

Question

Sto valutando i vantaggi di Zend_Config_Ini rispetto a un semplice file costante.

es. -

define('DB_HOST',localhost);

//versus

$config = new Zend_Config_Ini('/path/to/config.ini', 'staging');
echo $config->database->params->host;   // prints "dev.example.com"

L'unica cosa è che $ config non è accessibile a livello globale. Quindi è necessario utilizzare Zend_Registry per archiviare per l'utilizzo dell'applicazione, senza dover iniziare ogni volta.

Questo sembra aggiungere più complessità del necessario .... Mi sto perdendo qualcosa o Zend_Config + Zend_Registry è una tecnica che è migliore nel lungo periodo man mano che un'app cresce?

Answer 1

Il principale vantaggio dell'uso del Registro di sistema con una configurazione è di evitare di inquinare lo spazio dei nomi globale. Ad esempio, vuoi includere una libreria di terze parti e la tua app e la libreria definiscono entrambe un DB_HOST costante. Non va bene.

Inoltre, molte delle fabbriche di Zend Framework utilizzano l'oggetto config per creare istanze. Zend_Db ne è un buon esempio. Basta passare $ this- > database e ci vorrà tutto il necessario per creare un'istanza dell'adattatore.

Puoi anche estendere il registro con funzionalità personalizzate, ad es. metodi di ricerca o cose del genere. Controlla la descrizione del modello di Fowler.

Answer 2

Un bel vantaggio di Zend_Config è che non dipendi da un file di codice sorgente PHP " ; farà solo un file .ini - e alcuni preferiscono modificare un file .ini anziché uno PHP.

Ed è più semplice modificare un file .ini / XML a livello di codice - ci sono classi / funzioni per farlo!

Con i file .ini e Zend_Config , hai anche delle belle funzionalità già fornite; ad esempio, l'ereditarietà tra le sezioni (ad esempio, puoi avere una sezione "generica" ??e "messa in scena" e "produzione" che sovrascrivono alcuni valori)

Una cosa che può essere interessante su Zend_Config è anche la coerenza: Zend Framework, con Zend_Application , suppone già che avrai un file di configurazione; quindi, perché non un secondo? O anche riutilizzare il primo?

Ed è lo stesso con diverse classi del Framework, che possono funzionare o essere configurate con un'istanza di Zend_Config ; se ne hai già uno, diventa improvvisamente più facile ;-)

Se dovessi scegliere tra un file PHP con define e un file .ini, per cose che sono configurabili, probabilmente andrei con il file .ini (E Zend_Config + Zend_Registry quando necessario) .

Answer 3

Sì, hai ragione, usare il metodo sanzionato Zend per la configurazione è più complesso della definizione di una serie di costanti globali. I vantaggi che ottieni sono

Nessuna collisione globale dello spazio dei nomi

Se hai mai bisogno di integrare la tua applicazione con un altro progetto, avere costanti globali che rappresentano la tua configurazione dell'applicazione potrebbe causare problemi. Quali sono le probabilità che un altro progetto abbia una costante denominata DB_HOST ? Come può uno sviluppatore che sta usando il tuo sistema ibrido dire quali costanti sono la configurazione per la tua applicazione rispetto all'applicazione integrata?

Basandosi sul lavoro degli altri

Quindi, hai un singolo file con tutti i tuoi valori di configurazione. Come lo distribuirai in ambienti diversi? (produzione, messa in scena, ecc.) È probabile che tu sia una persona intelligente che potrebbe trovare una soluzione, ma in che modo un altro sviluppatore che entra nel tuo progetto saprà come funziona quella soluzione? In che modo altri moduli della tua applicazione sapranno leggere la tua configurazione globale?

Zend_Config ha già " risolto " molti dei problemi. Assumendo un po 'più di complessità e astrazione in anticipo, ottieni un percorso noto in avanti e puoi dedicare più tempo a risolvere i problemi della tua applicazione invece di inventare e supportare Yet Another Configuration System.