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

Question

Я пытаюсь выбрать наилучший способ сохранения настроек конфигурации моих приложений. Есть так много вариантов.

В большинстве приложений, которые я видел, использовался простой файл require и файл PHP, содержащий переменные. Там, кажется, есть гораздо более продвинутые методы.

Что ты использовал? Что наиболее эффективно? Что наиболее безопасно?

Answer 1

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

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

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

Setting::URL

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

Answer 2

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

Этот метод позволяет вам написать конфигурацию приложения следующим образом: app.config.php

<?php

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

Этот метод является безопасным, с возможностью кэширования с помощью кодов операций (APC, XCACHE).

Answer 3

Лучшее, что вы можете сделать, это простейшая вещь, которая может сработать (переменные php) и обернуть ее в классе. Таким образом, вы можете изменить реализацию позже, не меняя код клиента. Создайте интерфейс, который реализует класс конфигурации, и заставьте код клиента использовать методы интерфейса. Если позже вы решите сохранить конфигурацию в базе данных, JSON или где-либо еще, вы можете просто заменить существующую реализацию новой. Убедитесь, что ваш класс конфигурации тестируемый, и напишите модульные тесты.

Answer 4

Как насчет:

; <?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 (;), поэтому он не будет иметь никакого эффекта.

Answer 5

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

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

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

Кроме того, использование файлов INI с Zend_Config позволяет вам определять разделы конфигураций, которые наследуются друг от друга. Чаще всего используется раздел «разработка», который наследуется от раздела «производство», а затем переопределяет параметры БД / отладки.

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

Answer 6

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

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

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

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

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

Примечание. Для чтения ini-файлов необходимо использовать функцию parse_ini_file .

Answer 7

Просто пример того, как реализовать центральную конфигурацию 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');

Answer 8

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

так что вы можете иметь:

db.default.user

или

db.readonly.user

и т. Д.

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

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

Answer 9

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

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

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

Answer 10

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

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