Какой вариант выборки настроек использовать в php-проекте?

Question

[Quber]

Есть настройки в конфиг. файле. Каким способом лучше всего их выбирать при условии, что количество настроек может быть до 1000? Варианты:

echo $cfg->get('newsImageWidth');
echo $cfg->get('news','image','width');
echo $cfg->get('news')['image']['width']; // php 5.5
// Ваш вариант

Какой вариант используется у Вас / известных Вам CMS?

Answer 1

[Андрей]

Хранить конфигурацию в ini файле.
Использовать parse_ini_file c парсингом секций в отдельные массивы.
Использовать ArrayAccess для доступа к полям конфигурации.

Comments

[Quber]

@kaasius спасибо

Answer 2

[dmeroff]

Как насчет использования ArrayAccess? В таком случае выборка настроек будет выглядеть так:

echo $cfg['news'];
echo $cfg['news']['image'];
echo $cfg['news']['image']['width'];

Comments

[Андрей]

По ощущениям наиболее козырный вариант, без нелепого парсинга дот-нотации.

[Quber]

@dmeroff спасибо

Answer 3

[Yakov Akulov]

предпочитаю
echo $cfg->get('news.image.width');
Имеем разделение настроек по неймспейсу.
Все настройки в рантайме храним в одном массиве.
При инициализации можно этот массив собирать из нескольких кусков (при необходимости кэшировать, хотя если настройки храняться в php-файле, то достаточно будет кэширования самого скрипта apc, xcache etc).

Если вызываем
$cfg->get('news.image');
получаем полный массив настроек, так иногда удобно, чтобы лишних вызовов функций не было.

Comments

[Quber]

@jakulov спасибо, буду иметь ввиду

[Андрей]

То есть при каждом обращении к cfg будут парситься строки? В этом случае кеширование или не кеширование не даст никакого эффекта - все сожрет парсинг.

[Сергей Протько]

@kaasius не думаю что в вашем приложении это станет узким местом. Если вы будете применять какой-нибудь контейнер зависимостей, то тогда большую часть времени парсинга удастся невилировать, ибо можно закешить весь контейнер, который уже запросил нужные настройки.

[Сергей Протько]

@kaasius да и вообще, парсинг строк такого рода это копейки по сравнению с подключением к базе и выполнением хоть самого элементарного запроса в базу, не говоря о доступе к файловой системе и т.д.

[Андрей]

@Fesor Это слегка усложнит логику приложения. И да - если в конфиге может быть 1000 настроек, то и в приложении может быть 1000 парсингов.

[Андрей]

@Fesor Подключение к базе redis выполняется за 50 микросекунд примерно. Выборка данных из redis по ключу выполняется… ну тоже быстро. Вы видимо привыкли, что база - всегда мускуль. Постройте сайт, на котором будет миллион хостов за сутки, и вы научитесь писать оптимальный код.

[Yakov Akulov]

@kaasius да ладно, парсинг explode('.', $str) сожрет все время?
Смешно же. Далее идет такой же доступ по спрасенному массиву к инкапсулированному внутрь класса кофигураций array или ArrayAccess.
Мне нравится такой вариант, т.к. имхо проще отслеживать доступ к той или иной настройке в коде по конструкции "configNs.configParam"
нежели "["configNs"]["ConfigParam"]". Ну и как-то аккуратней код смотрится, когда лишняя работа с массивами спрятана внутрь служебного класса. Но это уже субъективно, конечно.

[Quber]

@jakulov что то в этом есть..

[Андрей]

@jakulov explode 1000 строчек - это 0,5 ms, parse_ini_file - 0.06 ms - разница - на порядок. Может показаться, что полмилисекунды - не так много. Это так, когда страница собирается 100-500 ms. Но возможно добиться и такого, чтобы она собиралась 5 ms, и тогда это уже 10%.

[Yakov Akulov]

@kaasius откуда такие замеры?
у меня на 5.4 получается parse_ini_file с 1000 параметров порядка 0,001 s
explode 1000 строк - порядка 0,0015 s
разницы на порядок получить никак немогу

Answer 4

[gro]

$cfg->news->image->width

Comments

[Андрей]

Для этого надо еще распарсить в кучу объектов конфигурацию. Это дороговато будет стоить.

[gro]

@kaasius, ну, парсить можно только нужное и в момент запроса. Заодно, в отличии от одного массива, это позволит разделить конфиг на множество файлов и подключать только необходимые.
И это не та дороговизна о которой стоит думать.

[Андрей]

Дак, ini файлы тоже можно держать в большем количестве, чем один. И парсить только нужные.