my_config.ini vs my_config.php

Question

На работе мы используем INI-файл для установки переменных до вызова остальной части фреймворка (я думаю, что это идет

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

и я всегда задавался вопросом, была ли польза от этого таким образом.

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

Итак, зачем использовать my_config.ini вместо my_config.php? Никто не должен прикасаться к нему после его настройки, и кажется более удобным просто вызывать переменные и иметь возможность автоматически заполнять текст в IDE везде, где вы используете переменные ini / анализировать его на наличие ошибок.

Answer 1

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

Мой сценарий тестирования - это файл config.ini с 20 парами ключ / значение и config.php файлом с теми же 20 парами ключ / значение, записанными как определено. Версия PHP 5.4.9 для Ubuntu Linux 13.04.

key1 = value1
...
key20 = value20

против

<?php
define("key1", "value1");
...
define("key2", "value20");

Два тестовых скрипта, включая конфиги:

<?php
$CONF = parse_ini_file("config.ini");

против

<?php
require_once "config.php";

Я проверил производительность с ab -c 25 -n 10000.

Результат без PHP-кэша:

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

Результат с PHP-кешем APC:

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

Я запускал тесты несколько раз, естественно, числа будут меняться каждый раз, но согласие таково: config.ini немного быстрее, когда не используется кеш PHP, config.php немного быстрее, когда кеш PHP используемый. Но разница настолько мала, что решение не должно основываться на производительности.

Answer 2

Ваш вопрос, безусловно, поднимает вопрос.

Несколько баллов в пользу .ini файлов:

• Использовать файл на другом языке . Если вы когда-нибудь хотели, чтобы скрипты Perl, Python, Ruby и т. Д. Делали что-то, что особенно легко с этим языком и требовалось для доступа к настройкам проекта, вам не повезло бы, если бы вы сохранили свои настройки в файле PHP.

• Редактирование данных человеком . Несмотря на то, что вы отклонили это в своем вопросе, намерениях или нет, весьма вероятно, что кто-то может в итоге засоваться туда, и это может быть не технический человек. Формат INI намного менее страшен, чем код PHP, даже если это просто набор объявлений переменных

• Обновление настроек . Я думаю, что гораздо проще создать новый файл INI, чем писать файл PHP. Это довольно субъективно, но стоит упомянуть.

• Связь между установочными переменными . Довольно просто / интуитивно понятно настроить параметры в виде файла INI. Хотя это также возможно в PHP, это не так аккуратно и может показаться неприглядным, если вы пытаетесь создать глубоко вложенные ассоциативные массивы для хранения информации.

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

Answer 3

Zend Framework содержит анализ конфигурации, который анализирует файлы, записанные в формате ini ( Zend_Config_Ini ), похоже, именно это вы используете.

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

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

со страницы Zend_Config_Ini .

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

Конечно, это было бы возможно с PHP-скриптом, но это потребовало бы большего разбора различных переменных конфигурации, а также выполнения проверок if / then, тогда как использование parse_ini_file () делает все это автоматически.

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

Пример с сайта, над которым я сейчас работаю:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

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

Answer 4

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

Я обнаружил, что осторожное размещение <?php и ?> может помешать его отображению, в то время как parse_ini_file () все равно получит соответствующие данные из файла.

Лучший способ обезопасить его - разместить его над докрутом и запретить доступ к * .ini в настройках вашего сервера.