PHP-файл конфигурации приложения, хранящийся как-ini, php, sql, cached, php class, JSON, PHP array?

мы используем файл с названием Local.php, который исключен из системы SCM. Он содержит несколько констант и глобальных переменных. Например:

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

и это можно отнести к в любом месте просто:

Setting::URL

Если вам нужны параметры для записи во время выполнения, я предлагаю вам использовать общедоступные статические переменные.

попробуйте использовать файлы конфигурации php-массивов, используя метод, описанный здесь: http://www.dasprids.de/blog/2009/05/08/writing-powerful-and-easy-config-files-with-php-arrays

этот метод позволяет писать конфигурацию приложения таким образом: приложение.конфиг.в PHP

<?php

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

этот метод является безопасным, кэшируемым cachers (APC, XCACHE).

найти Zend_Config быть хорошим решением. Вы можете загрузить конфигурация из простого массива С файл в стиле INI или XML-документ. Какой бы вы ни выбрали, объект конфигурации одинаков, поэтому вы можете свободно переключать форматы хранения. Zend_Config объекты также могут быть объединены, в зависимости от вашего приложения это может быть полезно (конфигурация сервера, затем конфигурация сайта/установки).

As с большинством (или всеми) вещей в Zend Framework вы можете легко использовать Zend_Config сам по себе.

учитывая эффективность, Я бы сказал, что самый быстрый метод - использовать массив, так как для этого требуется меньше (в данном случае нет) синтаксического анализа строк. Тем не менее, формат INI / XML может быть проще для некоторых. Конечно, некоторые кэширование даст вам лучшее из обоих миров.

кроме того, используя INI-файлы с Zend_Config позволяет определить разделы конфигураций, которые наследуются друг от друга. Наиболее распространенным является раздел "разработка", который наследуется от раздела "производство", а затем переопределяет параметры DB/debugging.

Что касается безопасности, сохранив файл конфигурации из корневого web-каталога это первый шаг. Сделать его только для чтения и ограничения доступа может сделать это больше безопасный; однако, в зависимости от вашей конфигурации хостинга/сервера вы можете быть ограничены в том, что можно сделать там.

как насчет:

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

Сохранить как config.php (или что-то в этом роде, должно иметь расширение php), а затем просто загрузите его с помощью:

parse_ini_file('config.php', true);

и вы могли бы использовать

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

чтобы объединить файл конфигурации по умолчанию с более конкретным файлом конфигурации.

дело в том, что вы можете использовать очень читаемый формат ini, но все же иметь свой конфигурационный файл в общедоступном каталоге. Когда вы откроете файл с помощью браузера, php сначала проанализирует его и дать вам результат, который будет просто "; прямой доступ не допускается ;". Когда вы анализируете файл непосредственно как ini-файл, оператор PHP die будет прокомментирован в соответствии с синтаксисом ini (;), поэтому он не будет иметь никакого эффекта.

просто пример того, как реализовать центральную конфигурацию XML/Xpath.

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

пример вызова

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

на мой взгляд, хорошим решением будут ini-файлов.

Я не предпочитаю файл конфигурации с использованием массивов / переменных для хранения настроек; вот почему:

Что делать, если пользователь случайно переименовал вашу переменную настройки?
Что делать, если переменная с похожим именем определена в другом месте пользователем?
Переменные в конфигурационном файле могут быть перезаписаны где-то глубоко в скрипте или даже в включенных файлах.
и, возможно, еще больше проблем....

I как использовать ini-файл для настройки моих php-приложений. Вот почему:

Это раздел
Легче
Вы можете установить значения по именам
Вам не нужно беспокоиться о перезаписи переменных, потому что их нет.
Конечно, никакого конфликта переменных. Это позволяет более гибко определять типы значений.

Примечание: вам нужно использовать parse_ini_file

лучше всего сделать любую конфигурацию ядра в самом PHP, но если вы используете базу данных и не возражаете против дополнительных накладных расходов - вы можете найти некоторую гибкость в хранении некоторых настроек в базе данных с помощью одного дополнительного запроса (при условии, что вы организуете его правильно).

в любом случае, хранение этих данных в JSON, INI, XL и т. д.-Это просто еще одна ненужная абстракция, которая в настоящее время слишком много делается в интернете. Ваш лучший выбор-чистый PHP, если вам не нравится гибкость некоторых настроек быть в базе данных.

единственная причина, по которой я могу думать о том, чтобы не использовать php vars, как предлагают другие, - это если вам нужно переключаться между конфигурациями контролируемым образом, поэтому во время переключения есть согласованность данных/поведения. Например, если вы переключаете базы данных, система может записывать заблокированные до тех пор, пока не произойдет переключение (чтобы предотвратить запись призраков, но грязные чтения все еще возможны).

Если такие вещи вызывают беспокойство, вы можете написать специальную страницу администратора в своем приложении(pref локальный доступ только для безопасности), который временно блокирует систему, а затем считывает и развертывает все изменения перед разблокировкой.

Если вы используете сайт с высоким трафиком, где важна согласованность, это то, что вы захотите рассмотреть. Если вы можете развернуть в нерабочее время, когда мало/нет трафика, тогда php vars или другие стандартные текстовые форматы будут в порядке.

мне нравится идея иметь "пространства имен" или какое-то дерево

таким образом, вы можете иметь:

db.default.user

или

db.readonly.user

и так далее.

теперь относительно кода то, что я сделал, было интерфейсом для читателей конфигурации: так что вы можете иметь читателя памяти, читателя массива, читателя БД и т. д.

и класс конфигурации, который использует эти читатели и позволяет вам иметь конфигурацию из любого источника