PHP - ¿El archivo de configuración de la aplicación se almacena como - ini, php, sql, cached, php class, JSON, php array?

https://stackoverflow.com/questions/1809241

05-07-2019
|

Pregunta

Estoy tratando de decidir la mejor manera de almacenar los ajustes de configuración de mis aplicaciones. Hay tantas opciones.

La mayoría de las aplicaciones que he visto han usado un requisito simple y un archivo PHP que contiene variables. Parece que hay técnicas mucho más avanzadas que hay.

¿Qué has usado? ¿Qué es más eficiente? ¿Qué es lo más seguro?

Solución

Lo mejor que puedes hacer es lo más simple que podría funcionar (variables php ) y envolverlo en una clase. De esa manera, puede cambiar la implementación más adelante sin cambiar ningún código de cliente. Cree una interfaz que implemente la clase de configuración y haga que el código del cliente use los métodos de la interfaz. Si más tarde decide almacenar la configuración en una base de datos o JSON o lo que sea, simplemente puede intercambiar la implementación existente por una nueva. Asegúrese de que su clase de configuración sea verificable y escriba pruebas de unidad.

Otros consejos

Usamos un archivo llamado Local.php que está excluido del sistema SCM. Contiene varias constantes o variables globales. Por ejemplo:

// Local.php
class Setting
{
   const URL = 'http://www.foo.com';
   const DB_User = 'websmith';
}

Y se puede referir a en cualquier lugar simplemente mediante:

Setting::URL

Si necesita que la configuración se pueda escribir en el tiempo de ejecución, le sugiero que utilice variables estáticas públicas en su lugar.

Intente usar los archivos de configuración php-arrays usando la técnica descrita aquí: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays

Este método le permite escribir la configuración de la aplicación de esta manera: app.config.php

<?php

return array(
  'appname' => 'My Application Name',
  'database' => array(
    'type' => 'mysql',
    'host' => 'localhost',
    'user' => 'root',
    'pass' => 'none',
    'db' => 'mydb',
  ),
);

Este método es seguro y se puede almacenar en caché mediante cachers de código de operación (APC, XCACHE).

Encuentro Zend_Config para ser una buena solución. Puede cargar la configuración de desde una matriz simple , desde un archivo de estilo INI , o desde un documento XML . Sea cual sea su elección, el objeto de configuración es el mismo, por lo que puede cambiar los formatos de almacenamiento libremente. Los objetos Zend_Config también se pueden combinar, dependiendo de su aplicación, esto puede ser útil (una configuración de servidor, luego una configuración de sitio / instalación).



 Como con la mayoría (o todas) las cosas en Zend Framework, puedes usar  Zend_Config  fácilmente por sí mismo. 

  Teniendo en cuenta la eficiencia , diría que el método más rápido sería utilizar una matriz, ya que requiere menos análisis de cadenas (en este caso, no). Sin embargo, un formato INI / XML puede ser más fácil de mantener para algunos. Por supuesto, un almacenamiento en caché le dará lo mejor de ambos mundos. 

 Además, el uso de archivos INI con  Zend_Config  le permite definir secciones de configuraciones que se heredan unas de otras. El uso más común es una sección de 'desarrollo' que se hereda de la sección 'producción', luego redefine la configuración de DB / debugging. 

  En cuanto a la seguridad , mantener el archivo de configuración  fuera de la raíz web  es el primer paso. Hacerlo solo para leer y limitar el acceso podría hacer que  más  sea seguro; sin embargo, dependiendo de la configuración de su servidor / servidor, puede estar limitado en lo que se puede hacer allí.



	
		
	
	
			 Cómo sobre: ??

; <?php die('Direct access not allowed ;') ?>
; The above is for security, do not remove

[database]
name = testing
host = localhost
user = root
pass = 

[soap]
enableCache = 1
cacheTtl = 30


 Guardar como config.php (o algo así, debe tener extensión php), y luego cargarlo con: 

parse_ini_file('config.php', true);


 Y podrías usar 

array_merge_recursive(parse_ini_file('config-default.php', true), parse_ini_file('config.php', true))


 para combinar un archivo de configuración predeterminado con un archivo de configuración más específico. 

 El punto aquí es que puede usar el formato ini muy legible, pero aún así puede tener su archivo de configuración en un directorio público.
Cuando abra el archivo con su navegador, php lo analizará primero y le dará el resultado, que simplemente será " ;; Acceso directo no permitido; " ;. Cuando analice el archivo directamente como un archivo ini, la instrucción php die se comentará de acuerdo con la sintaxis ini (;) para que no tenga ningún efecto en ese momento. 
	


	
		
	
	
			 Solo un ejemplo de cómo implementar una configuración central de XML / Xpath. 

class Config {
    private static  Solo un ejemplo de cómo implementar una configuración central de XML / Xpath. 

Config::getInstance()
    ->open('settings.xml')
    ->getConfig('/settings/module/section/item');


 Ejemplo de llamada 

<*>singleton;
    private $xml;
    static function getInstance() {
        if(is_null (self:: Solo un ejemplo de cómo implementar una configuración central de XML / Xpath. 

<*>

 Ejemplo de llamada 

<*>singleton) ) {
                self:: Solo un ejemplo de cómo implementar una configuración central de XML / Xpath. 

<*>

 Ejemplo de llamada 

<*>singleton = new self;
        }
        return self:: Solo un ejemplo de cómo implementar una configuración central de XML / Xpath. 

<*>

 Ejemplo de llamada 

<*>singleton;
    } 
    function open($xml_file) {
        $this->xml = simplexml_load_file($xml_file);
        return $this;
    }
    public function getConfig($path=null) {
        if (!is_object($this->xml)) {
            return false;
        }
        if (!$path) {
            return $this->xml;
        }
        $xml = $this->xml->xpath($path);
        if (is_array($xml)) {
            if (count($xml) == 1) {
                return (string)$xml[0];
            }
            if (count($xml) == 0) {
                return false;
            }
        }
        return $xml;
    }
}


 Ejemplo de llamada 

<*>	


	
		
	
	
			 En mi opinión, una buena solución serían los archivos ini. 

 No prefiero el archivo de configuración que usa matrices / variables para almacenar configuraciones; Aquí es por qué: 

  ¿Qué sucede si un usuario cambia el nombre de su variable de configuración accidentalmente? 

¿Qué sucede si el usuario también define una variable con un nombre similar en otra parte? 

Las variables en el archivo de configuración se pueden sobrescribir en algún lugar del script o incluso en los archivos incluidos. 

y posiblemente más problemas ...  

 Me gusta usar el archivo ini para configurar mis aplicaciones php. Aquí es por qué: 

  Se basa en la sección 

Es mas facil 

Puedes establecer valores por nombres amigos 

No tiene que preocuparse por las variables que se sobrescriben porque no hay ninguna. 

No hay conflicto de variables por supuesto.
Permite una mayor flexibilidad en la especificación de los tipos de valores.  

 Nota: necesitas usar la función  parse_ini_file  para leer archivos ini. 
	


	
		
	
	
			 Es mejor hacer cualquier configuración de núcleo en el propio PHP, pero si está utilizando una base de datos y no le importa la sobrecarga adicional, puede encontrar cierta flexibilidad para almacenar algunas configuraciones en la base de datos con una sola consulta adicional (suponiendo lo organizas adecuadamente). 

 De cualquier manera, almacenar estos datos en JSON, INI, XL, etc. es solo otra abstracción innecesaria que se hace demasiado hoy en día en la web. Su mejor apuesta es PHP puro, a menos que le guste la flexibilidad de algunas configuraciones en la base de datos. 
	


	
		
	
	
			 La única razón por la que puedo pensar en no usar vars php, como sugieren otros, es si necesita cambiar entre las configuraciones de manera controlada, por lo que hay una consistencia de datos / comportamiento durante el cambio. Por ejemplo, si está cambiando las bases de datos, entonces el sistema podría escribir bloqueado hasta que se produzca la conmutación (para evitar escrituras fantasma, pero las lecturas sucias todavía son posibles). 

 Si le preocupa algo como esto, podría escribir una página de administración especial en su aplicación (acceso local solo por seguridad) que bloquea el sistema temporalmente, luego lee y despliega todos los cambios antes de desbloquear. 

 Si está ejecutando un sitio de alto tráfico donde la consistencia importa, esto es algo que querrá considerar. Si puede realizar la implementación fuera de las horas de trabajo cuando hay poco tráfico o no, las vpp u otros formatos de texto estándar estarán bien. 
	


	
		
	
	
			 Me gusta la idea de tener " espacios de nombres " o algún tipo de árbol 

 para que puedas tener: 

db.default.user


 o 

db.readonly.user


 y así sucesivamente. 

 ahora con respecto al código, lo que hice fue una interfaz para los lectores de configuración: para que pueda tener un lector de memoria, un lector de matriz, un lector de db, etc. 

 y una clase de configuración que utiliza esos lectores y te permite tener una configuración de cualquier tipo de fuente



	
		
			Licenciado bajo: CC-BY-SA con atribución
			No afiliado a StackOverflow