PHP Zend Framework - Zend_Config y estado global

Question

Estoy en el proceso de evaluar los beneficios de Zend_Config_Ini en lugar de usar un archivo constante simple.

por ejemplo -

define('DB_HOST',localhost);

//versus

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

Lo único es que $ config no es accesible globalmente. Entonces necesita usar Zend_Registry para almacenar para el uso de la aplicación, sin tener que iniciar cada vez.

Esto parece agregar más complejidad de la necesaria ... ¿me falta algo o es Zend_Config + Zend_Registry una técnica que es mejor a largo plazo a medida que crece una aplicación?

Answer 1

La principal ventaja de usar el Registro con una configuración es evitar contaminar el espacio de nombres global. Digamos que desea incluir una biblioteca de terceros y su aplicación, y la biblioteca de ambos define un DB_HOST constante. No es bueno.

Además, muchas de las fábricas en Zend Framework utilizan el objeto de configuración para crear instancias. Zend_Db es un buen ejemplo de esto. Simplemente pase el código $ this- > database y tomará lo que necesite para crear una instancia de su adaptador.

También puede ampliar el registro con una funcionalidad personalizada, por ejemplo. Métodos de búsqueda o cosas por el estilo. Consulte la descripción del patrón de Fowler.

Answer 2

Una buena ventaja de Zend_Config es que no dependes de un " archivo de código fuente PHP " ; solo un archivo .ini servirá, y algunos prefieren modificar un archivo .ini en lugar de uno de PHP.

Y es más fácil modificar un archivo .ini / XML mediante programación. ¡Hay clases / funciones para hacer eso!

Con los archivos .ini y Zend_Config , también tiene buenas funcionalidades ya proporcionadas; por ejemplo, herencia entre secciones (es decir, puede tener una sección " genérica " y " puesta en escena " y " producción que sobrescribe algunos valores)

Una cosa que puede ser interesante sobre Zend_Config , también, es su consistencia: Zend Framework, con Zend_Application , ya supone que tendrá un archivo de configuración; Entonces, ¿por qué no un segundo? ¿O incluso reutilizar el primero?

Y es lo mismo con varias clases de Framework, que pueden funcionar o configurarse con una instancia de Zend_Config ; si ya tienes esa, de repente se vuelve más fácil ;-)

Si tuviera que elegir entre un archivo PHP con define y un archivo .ini, para las cosas configurables, probablemente iría con el archivo .ini (y Zend_Config + Zend_Registry cuando sea necesario) .

Answer 3

Sí, está en lo correcto, usar el método de configuración autorizado por Zend es más complejo que definir una serie de constantes globales. Las ventajas que obtienes son

No hay colisiones en el espacio de nombres global

Si alguna vez necesita integrar su aplicación con otro proyecto, tener constantes globales representan la configuración de su aplicación puede causar problemas. ¿Cuáles son las posibilidades de que otro proyecto tenga una constante denominada DB_HOST ? ¿Cómo puede un desarrollador que usa su sistema híbrido indicar qué constantes son la configuración de su aplicación en comparación con la aplicación integrada?

Aprovechando el trabajo de otros

Entonces, tienes un solo archivo con todos los valores de configuración. ¿Cómo vas a implementar eso en diferentes entornos? (producción, puesta en escena, etc.) Es probable que usted sea una persona inteligente que pueda encontrar una solución, pero ¿cómo va a saber otro desarrollador en su proyecto cómo funciona esa solución? ¿Cómo sabrán otros módulos de su aplicación cómo leer su configuración global?

Zend_Config ya ha resuelto " " " Muchos de los problemas. Al asumir un poco más la complejidad y la abstracción por adelantado, obtiene un camino conocido hacia adelante y puede dedicar más tiempo a resolver los problemas de su aplicación en lugar de inventar y respaldar el Otro Sistema de Configuración.