my_config.ini против 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

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 2

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

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

Лучший способ обеспечить его, заключается в том, чтобы разместить его над docroot и запретить доступ к * .ini в настройках вашего сервера.

Answer 3

Ваш вопрос поднимает справедливую точку, чтобы быть уверенным.

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

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

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

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

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

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

Answer 4

Для тех, кто приходит к этому вопросу, потому что они хотят знать, есть ли различия в производительности между использованием файла 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"); 

vs.

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

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

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

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