proyecto para crear configurar php class configuration config-files

crear - ¿Es correcto establecer una clase de configuración PHP para mantener la configuración del proyecto?



configurar eclipse para php (3)

Creo que lo que quieres es la static-keyword!

class Config { static $DB_SERVER = ''localhost''; static $DB_NAME = ''abc''; static $DB_USERNAME = ''admin''; static $DB_PASSWORD = ''12345''; static $WEBSITE_NAME = ''My New Website''; static $IMAGE_DIR = ''img''; }

como eso. Puede llamarlos con :: , por ejemplo, Config::$DB_SERVER .

Por cierto Normalmente no las escribes así de grandes si son variables de clase. Grandes medios globales, por lo general.

Quiero crear un archivo config.php para mantener los diversos valores de configuración que generalmente se cambian de proyecto a proyecto, y quiero definir una clase para mantener los valores de configuración en este archivo como los siguientes:

class Config { const DB_SERVER = ''localhost'', DB_NAME = ''abc'', DB_USERNAME = ''admin'', DB_PASSWORD = ''12345'', WEBSITE_NAME = ''My New Website'', IMAGE_DIR = ''img''; }

y así sucesivamente, quiero definir todos los valores como constantes dentro de la clase, y los llamaré así:

$connection = mysql_connect(Config::DB_SERVER, Config::DB_USERNAME, Config::DB_PASSWORD) or die("Database connection failed..");

Quiero saber: ¿esta forma de configurar la configuración del proyecto es correcta? ¿Tiene esta manera alguna contras? Y si estaba mal, ¿cuál es la mejor manera de hacer esto?



Es una forma de hacerlo, sí. Una manera no muy mala, OMI. Básicamente, la clase se convierte en un archivo de configuración, solo con la sintaxis de PHP.

Hay un par de inconvenientes, sin embargo:

  • No puedes tener matrices u objetos const. (Por supuesto, tampoco puede tener arreglos / objetos constantes globales, así que ...) (Desde 5.6, puede tener arreglos constantes. Sin embargo, aún no hay objetos const. Estoy bastante seguro de que tampoco puede tener recursos const , ya que eso no tendría mucho sentido.)

    Puede solucionar esto implementando un getter estático para objetos (que, por supuesto, está codificado para devolver siempre el mismo objeto) ... pero lo recomendaría en la mayoría de los casos. Es solo una opción segura si los objetos en su configuración son inmutables por diseño. (Los objetos que no están diseñados para la inmutabilidad son demasiado fáciles de cambiar, incluso por accidente).

    (Aparte del problema de mutabilidad, me molesta tener un código de ejecución real en un archivo de configuración ... pero eso es principalmente una preferencia personal).

  • Esta clase tiene un propósito diferente al resto: está diseñada para cambiar por proyecto. Podría considerar mantener la clase Config en algún lugar aparte del resto de las clases, como donde normalmente mantendría un archivo de configuración.

  • Con un archivo de configuración real, ya que lo analiza en tiempo de ejecución, posiblemente podría tratar un archivo faltante o no válido (por ejemplo, ejecutando con la configuración predeterminada, usando qué partes son analizables y / o mostrando un mensaje de error útil). Pero una vez que su configuración se ejecuta como código PHP, cualquier error de sintaxis (o, si no lo ha tenido en cuenta, una clase Config faltante) detendrá la aplicación en seco. Y si está ejecutando con display_errors desactivado (recomendado en producción), el problema podría ser menos obvio.