my_config.ini против my_config.php

StackOverflow https://stackoverflow.com/questions/823352

  •  05-07-2019
  •  | 
  •  

Вопрос

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

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

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

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

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

Это было полезно?

Решение

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top