PHP - File di configurazione dell'applicazione memorizzato come - ini, php, sql, cache, classe php, JSON, array php?

Question

Sto cercando di decidere il modo migliore per memorizzare le mie impostazioni di configurazione delle applicazioni. Ci sono così tante opzioni.

La maggior parte delle applicazioni che ho visto hanno utilizzato un semplice require e un file PHP che contiene variabili. Sembrano esserci tecniche molto più avanzate là fuori.

Che cosa hai usato? Cosa è più efficiente? Cosa è più sicuro?

Answer 1

La cosa migliore che si può fare è the simplest thing that could possibly work (variabili php) e avvolgerlo in una classe. In questo modo è possibile modificare l'implementazione in un secondo momento senza modificare alcun codice client. Creare un'interfaccia che la classe di configurazione implementa e fare in modo che il codice client utilizzi i metodi dell'interfaccia. Se in seguito si decide di archiviare la configurazione in un database o JSON o qualsiasi altra cosa, è possibile semplicemente sostituire l'implementazione esistente con una nuova. Assicurati che la tua classe di configurazione sia testabile e scrivi i test unitari.

Answer 2

È preferibile eseguire qualsiasi configurazione di base in PHP, ma se si utilizza un database e non ci si preoccupa dell'overhead aggiuntivo, è possibile trovare una certa flessibilità nell'archiviazione di alcune impostazioni nel database con una singola query aggiuntiva (assumendo che tu lo organizzi correttamente).

In entrambi i casi, la memorizzazione di questi dati in JSON, INI, XL, ecc. È solo un'altra astrazione non necessaria che è fatta troppo oggi al giorno sul web. La soluzione migliore è PHP puro, a meno che non ti piaccia la flessibilità di alcune impostazioni nel database.

Answer 3

Trovo cheZend_Config sia una buona soluzione. È possibile caricare configuration from a simple array, da an INI style file o da an XML document. Qualunque sia la tua scelta, l'oggetto di configurazione è lo stesso, quindi puoi cambiare liberamente i formati di archiviazione. Gli oggetti Zend_Config possono anche essere uniti, a seconda dell'applicazione potrebbe essere utile (una configurazione del server, quindi una configurazione per sito/installazione).

Come con la maggior parte (o tutte) le cose in Zend Framework, è possibile utilizzare facilmente Zend_Config da solo.

Considerando l'efficienza, direi che il metodo più veloce sarebbe utilizzare un array, poiché richiede meno (in questo caso nessuna) analisi delle stringhe. Tuttavia, un formato INI/XML potrebbe essere più facile da mantenere per alcuni. Certo, alcuni caching ti darebbero il meglio di entrambi i mondi.

Inoltre, l'utilizzo dei file INI con Zend_Config consente di definire sezioni di configurazioni che si ereditano l'una dall'altra. L'uso più comune è una sezione "sviluppo" che eredita dalla sezione "produzione", quindi ridefinisce le impostazioni di DB/debug.

quanto riguarda la sicurezza, mantenendo il file di configurazione fuori della web root è il primo passo. Farlo leggere solo e limitare l'accesso potrebbe renderlo più sicuro; tuttavia, a seconda della configurazione del tuo hosting/server, potresti essere limitato a ciò che può essere fatto lì.

Answer 4

Utilizziamo un file denominato Local.php che è escluso dal sistema SCM. Contiene diverse costanti o variabili globali.Per esempio:

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

E può essere definito ovunque semplicemente:

Setting::URL 

Se è necessario le impostazioni di essere scrivibile in fase di esecuzione, vi suggerisco di utilizzare variabili statiche pubbliche, invece.

Answer 5

tenta di utilizzare php-array file di configurazione utilizzando la tecnica descritta qui: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays

Questo metodo consente di scrivere la configurazione applicazione in questo modo: app.config.php

<?php 

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

Questo metodo è sicuro, in grado di cache tramite opcode cachers (APC, XCACHE).

Answer 6

L'unica ragione per cui posso pensare di non utilizzare php vars come altri suggeriscono è se è necessario passare da una configurazione all'altra in modo controllato, quindi c'è coerenza di dati/comportamento durante lo switch. Ad esempio, se si stanno passando da un database all'altro, il sistema potrebbe scrivere bloccato finché non si verifica il passaggio (per impedire le scritture fantasma, ma le letture sporche sono ancora possibili).

Se cose come questa sono un problema, allora si potrebbe scrivere una pagina speciale di amministrazione nella vostra applicazione (accesso locale pref solo per la sicurezza) che blocca temporaneamente il sistema, quindi legge e dispiega tutte le modifiche prima di sbloccare.

Se stai gestendo un sito ad alto traffico in cui la coerenza è importante, questo è qualcosa che vorrete considerare. Se è possibile distribuire durante le ore di riposo quando c'è poco traffico o no, quindi php vars o altri formati di testo standard andranno bene.

Answer 7

Solo un esempio di come implementare una configurazione XML/Xpath centrale.

class Config { 
    private static $_singleton; 
    private $xml; 
    static function getInstance() { 
     if(is_null (self::$_singleton)) { 
       self::$_singleton = new self; 
     } 
     return self::$_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; 
    } 
} 

Esempio chiamano

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

Answer 8

mi piace l'idea di avere "namespace" o un qualche tipo di albero

così si può avere:

db.default.user 

o

db.readonly.user 

e così via.

ora per quanto riguarda il codice quello che ho fatto è stato di un'interfaccia per i lettori di configurazione: in modo da poter disporre di un lettore di memoria, lettore di matrice, lettore di db, ecc

e una classe di configurazione che utilizza quei lettori e consentono di avere una configurazione da qualsiasi tipo di fonte

Answer 9

ne dite:

; <?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 

Salva come config.php (o qualcosa del genere, devono avere php estensione), e poi basta caricarlo con:

parse_ini_file('config.php', true); 

e si potrebbe utilizzare

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

di unire un file predefinito di configurazione con un file di configurazione più specifica .

Il punto qui è che è possibile utilizzare il formato ini leggibile, ma è comunque possibile avere il file di configurazione in una directory pubblica. Quando apri il file con il tuo browser, php lo analizzerà per primo e ti darà il risultato, che sarà solo "; Accesso diretto non consentito;". Quando si analizza il file direttamente come un file ini, l'istruzione php die verrà commentata in base alla sintassi ini (;), quindi non avrà alcun effetto.

Answer 10

Dal mio punto di vista la buona soluzione sarebbe ini file.

Non preferisco il file di configurazione utilizzando matrici/variabili per la memorizzazione delle impostazioni; ecco perché:

Cosa succede se un utente ha rinominato accidentalmente la variabile di impostazione?
Cosa succede se una variabile con nome simile è definita anche altrove dall'utente?
Le variabili nel file di configurazione possono essere sovrascritte in alcune parti dello script o persino nei file inclusi.
e forse più problemi ....

Mi piace usare il file ini per l'impostazione delle mie app di php. Ecco perché:

Si tratta sezione basata
E 'più facile
È possibile impostare valori da nomi descrittivi
Non dovete preoccuparvi di variabili sovrascrittura perché non ci sono quelli.
Nessun conflitto di variabili, ovviamente. Consente una maggiore flessibilità nella specifica dei tipi di valori.

Nota: è necessario utilizzare parse_ini_file funzione per leggere i file ini.