Pull to refresh

Comments 6

А в чем преимущества этого подхода перед обычным и быстрым parse_ini_file()?

Ну сравнение ИМХО не очень корректно. Symfony отделяет структуру конфигурации от формата источника. Вы можете хранить конфигурацию не только в .ini, но и в нативном php (что для новичков более предпочтительно, а для некоторых олдскульщиков ещё и удобно, т.к. не нужно напрягаться), а также в .yml, который с моей точки зрения является более удобным для конфигураций, т.к. по природе своей лаконичен, интуитивно понятен (пример, кстати, можно посмотреть, например, в конфигах системы деплоя Magallanes) и никак не зависит от php, что даёт преимущества при переезде / скрещивании проекта с другими языками и платформами. Но и опять же, с точки зрения архитектуры приложения отделение структуры от методов загрузки и хранения — правильно, т.к. позволяет менять данные ветви логики в независимости друг от друга, что облегчает масштабируемость приложения. Другое дело, что в Symfony иногда перегибают мальца с абстракциями =)

И все эти и yml, и php, и json, и проч. великолепно конвертятся в нативные php массивы. В результате достаточно было обычной конфиго-репы, принимающий array на вход и пара драйверов, конвертящих внешние форматы в этот array.

тоже, считаю, что симфони переусложнили компонент. поэтому он и не пользуется особой популярностью.

У INI файлов по сравнению с другими форматами конфигурации есть один недостаток — отсутствие возможности организовывать естественную иерархию более чем в 2 уровня. Да и нет возможности выполнять валидацию.

Zend_Config_Ini позволяет строить древовидную структуру из INI-файла с неограниченным количеством уровней.
Валидации нет, правда. Да и переиспользование и интерполяция работать не будут.
С другой стороны не придется возиться с кэшированием и инвалидированием, создавать эти массивные TreeBuilder'ы.


В общем, в отрыве от Symfony, мне кажется, этот компонент требует слишком много внимания к себе.

Sign up to leave a comment.

Articles