my_config.ini vs my_config.php

В 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 

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

Для тех, кто приходит к этому вопросу, потому что они хотят знать, есть ли различия в производительности между использованием файла 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 : config.ini немного быстрее, когда не используется кеш PHP, config.php немного быстрее при использовании кеша PHP. Но разница настолько мала, что решение не должно основываться на производительности.

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

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

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

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

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

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

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

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

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

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