Я пытаюсь решить, как наилучшим образом сохранить настройки конфигурации моих приложений. Существует так много вариантов.
Большинство приложений, которые я видел, использовали простой запрос и PHP файл, содержащий переменные. Там, кажется, есть намного более продвинутые методы.
Что вы использовали? Что наиболее эффективно? Что наиболее безопасно?
Лучшее, что вы можете сделать, это простейшая вещь, которая может работать (переменные php) и завершать ее в классе. Таким образом, вы можете изменить реализацию позже, не изменяя код клиента. Создайте интерфейс, который реализует класс конфигурации, и сделайте код клиента использующим методы интерфейса. Если позже вы решите сохранить конфигурацию в базе данных или JSON или что-то еще, вы можете просто заменить существующую реализацию на новую. Убедитесь, что ваш класс конфигурации тестируется и записывает модульные тесты.
Мы используем файл с именем 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
Этот метод позволяет вам написать конфигурацию приложения таким образом: app.config.php
<?php
return array(
'appname' => 'My Application Name',
'database' => array(
'type' => 'mysql',
'host' => 'localhost',
'user' => 'root',
'pass' => 'none',
'db' => 'mydb',
),
);
Этот метод является безопасным, кэшируемым с помощью кэширования опкодов (APC, XCACHE).
Я считаю Zend_Config хорошим решением. Вы можете загрузить конфигурацию из простого массива, из стиль INI файл или из XML-документ. Какой бы вариант вы ни выбрали, объект конфигурации одинаков, поэтому вы можете свободно переключаться между форматами хранения. Объекты Zend_Config также могут быть объединены, в зависимости от вашего приложения это может быть полезно (конфигурация сервера, а затем конфигурация для сайта/установки).
Как и большинство (или всех) вещей в Zend Framework, вы можете легко использовать Zend_Config самостоятельно.
Учитывая эффективность, я бы сказал, что самым быстрым методом будет использование массива, поскольку для этого требуется меньше (в данном случае нет) синтаксического анализа строк. Однако формат INI/XML может быть проще для некоторых. Конечно, некоторое кэширование даст вам лучшее из обоих миров.
Кроме того, использование файлов INI с Zend_Config позволяет вам определять разделы конфигураций, которые наследуют друг от друга. Наиболее часто используемым является раздел "разработка", который наследуется от раздела "производство", а затем переопределяет параметры БД/отладки.
Что касается безопасности, то сохранение файла конфигурации из корня веб-сайта является первым шагом. Только чтение и ограничение доступа могут сделать его более безопасным; однако, в зависимости от конфигурации вашего хостинга/сервера, вы можете быть ограничены тем, что можно сделать там.
Как насчет:
; <?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 файлы.
Я не предпочитаю конфигурационный файл с использованием массивов/переменных для хранения настроек; вот почему:
Что делать, если пользователь случайно переименовал вашу переменную настройки?
Что делать, если переменная с аналогичным именем определяется в другом месте пользователем?
Переменные в файле конфигурации могут быть перезаписаны где-то в глубине script или даже включенных файлов.
и, возможно, больше проблем....
Мне нравится использовать ini файл для настройки моих php-приложений. Вот почему:
Это раздел, основанный на
Это проще
Вы можете установить значения дружественными именами
Вам не нужно беспокоиться о перезаписи переменных, потому что их нет.
Конечно, конфликт переменных.
Это позволяет более гибко определять типы значений.
Примечание. Для чтения ini файлов вам необходимо использовать функцию parse_ini_file.
Лучше всего делать любую конфигурацию ядра в самом PHP, но если вы используете базу данных и не обращаете внимания на дополнительные накладные расходы - вы можете найти некоторую гибкость при сохранении некоторых параметров в базе данных с помощью одного дополнительного запроса (при условии, что вы организуете его правильно).
В любом случае сохранение этих данных в JSON, INI, XL и т.д. - это еще одна ненужная абстракция, которая сегодня слишком много делается в Интернете. Ваш лучший выбор - это чистый PHP, если вам не нравится гибкость некоторых настроек, находящихся в базе данных.
Единственная причина, по которой я могу думать о том, чтобы не использовать php vars, как предлагают другие, заключается в том, что вам нужно переключаться между конфигурациями контролируемым образом, чтобы во время переключения переключались данные/поведение. Например, если вы переключаете базы данных, система может записывать блокировку до тех пор, пока не произойдет переключение (чтобы предотвратить запись призраков, но грязные чтения все еще возможны).
Если такие вещи вызывают беспокойство, тогда вы можете написать специальную страницу администратора в своем приложении (pref локальный доступ только для обеспечения безопасности), который временно блокирует систему, затем читает и разворачивает все ваши изменения перед разблокировкой.
Если вы используете сайт с высоким трафиком, где важна последовательность, это то, что вы хотите рассмотреть. Если вы можете развертывать в нерабочее время, когда трафика мало/нет, то php vars или другие стандартные текстовые форматы будут в порядке.
Мне нравится идея иметь "пространства имен" или какое-то дерево
чтобы вы могли:
db.default.user
или
db.readonly.user
и т.д.
теперь относительно кода, что я сделал, был интерфейсом для считывателей конфигураций, поэтому вы можете иметь считыватель памяти, считыватель массивов, считыватель db и т.д.
и класс конфигурации, который использует эти считыватели и позволяет вам иметь конфигурацию из любого источника