Как вы храните конфиги?

[cDLEON]

а потом езе один конфиг... и так будем до опупения плодить конфинг?
Для приложения должно быть достаточно одного конфига

Там, где требуется структура конфигов больше 2-ух уровней, а модуль к этому всему один - не правильная архитектура. Другими словами - модуль выполняет больше работы, чем требуется. Если поделить всё приложение на "модули" этой проблемы не возникает. У каждого модуля свои конфиги.
И, к тому же, мне вот очень интересно чем отличается пара файлов от 3-ёх уровневой системы конфигурации.
ИМХО этот ваш пост - бредятина.

 

[atv]

Почему не сохранить конфиг в кеше самому, сразу после того, как распарсил из XML?

А в кеше ты как, байт код собираешься хранить?

Там, где требуется структура конфигов больше 2-ух уровней, а модуль к этому всему один - не правильная архитектура.

Ого, вот это выводы.

P.S. Ребята, пора бы привыкнуть, что не бывает единственно правильного и удобного решения на все случаи жизни, тем более в программировании. Оценку нужно проводить по строгим критериям за и против в каждой конкретной ситуации.

 

[Lightning]

А в кеше ты как, байт код собираешься хранить?

Нет, значение переменных конфига сохранить.

 

[Alexandre]

Почему не сохранить конфиг в кеше самому, сразу после того, как распарсил из XML?

можно хранить и в кеше, все зависит от задачи
это опционально и очень спорно что лучше?
практика - это реальные замеры - но, возможно, это спичечная оптимизация

ри таком подходе каждый раз нужно проверять не изменился ли конфиг.

не обязательно
конфиг - генерится неким скриптом - он и перезапускает перегенерацию
результаты безусловно при необходимости можно кешировать

 

[atv]

Нет, значение переменных конфига сохранить.

так чем это отличается от

что конфиг переводиться из xml в PHP код, а потом из PHP кода интерпретатор переводит в байт-код

из xml в PHP преобразовывается один раз, о какой ненужной работе ты говоришь? И что ты называешь кешем, если там обычный PHP код - "значение переменных конфига".

Твоя фраза "Почему не сохранить конфиг в кеше самому, сразу после того, как распарсил из XML?", в данном случае, не имеет смысла.

 

[Lightning]

Нет, значение переменных конфига сохранить.

так чем это отличается от

что конфиг переводиться из xml в PHP код, а потом из PHP кода интерпретатор переводит в байт-код

Значение переменных конфига это не байт-код PHP-файла конфига.

И что ты называешь кешем

В данном случае кэширующие движки (eAccelerator, memcache, APC).

Твоя фраза "Почему не сохранить конфиг в кеше самому, сразу после того, как распарсил из XML?", в данном случае, не имеет смысла.

Фраза смысл имеет. Просто ты его не понял. Я обращался к Alexandre, он меня понял и ответил.

 

[Alexandre]

Lightning, в частностях atv прав
если конфиг представлен в нативном виде (в виде РНР кода), то особого смысла его кешировать нет

В данном случае кэширующие движки (eAccelerator, memcache, APC)

надо отличать кеширование байткода eAccelerator, xCache, ZOptimaser, APC от кеширования данных: _memcache, memcachedb, ZCache

 

[Lightning]

надо отличать кеширование байткода eAccelerator, xCache, ZOptimaser, APC от кеширования данных: _memcache, memcachedb, ZCache

Почему именно такое разделение? APC и eAccelerator могут кешировать и данные.