Comments 15
Я пока еще не дочитал, но вот первый вопрос такой: для чего сделаны врапперы над __call, __callStatic и __construct?
«Магия» — не очень хорошо, я бы сделал иначе:
Простенький генератор моделей (должно быть, наверняка, что-то готовое), который сгенерит (перегенерит) все методы для всех полей с учётом кеширования, в т.ч. и через мемкешы, редисы,etc.
Простенький генератор моделей (должно быть, наверняка, что-то готовое), который сгенерит (перегенерит) все методы для всех полей с учётом кеширования, в т.ч. и через мемкешы, редисы,etc.
Метод неплох, но есть несколько замечаний:
1. Инициализация кэша не должна выполняться внутри данного класса. У ZF для этого есть bootstrap и конфиг. Лучше сделать статические методы getCache и setCache, которые бы запускались из bootstrap.
2. Было бы неплохо указать, что этот класс работает только в PHP 5.3
1. Инициализация кэша не должна выполняться внутри данного класса. У ZF для этого есть bootstrap и конфиг. Лучше сделать статические методы getCache и setCache, которые бы запускались из bootstrap.
2. Было бы неплохо указать, что этот класс работает только в PHP 5.3
Спасибо за замечания. Инициализацию кэша действительно можно вынести, в моем классе показана идея для понимания что именно мы делаем и про какие вещи не стоит забывать. По поводу версии php 5.3 я внес правки в статью.
>> Лучше сделать статические методы getCache и setCache, которые бы запускались из bootstrap.
уточнил бы, что лучше сделать статические методы getDefaultCache setDefaultCache и нестатические getCache и setCache
уточнил бы, что лучше сделать статические методы getDefaultCache setDefaultCache и нестатические getCache и setCache
А разве родной frontend class не тоже самое делает?
Проксирование вызовов методов модели тут выглядит как уродливый костыль. Также, с вашим кодом надо создавать мусорный класс к каждой модели. а еще не забыть перечислять все модифицирующие методы как некешируемые. У вас самого нет ощущения явного несовершенства мира^W получившейся системы?
Кеш должен ставиться где-то в репозитории/table gateway, так как он знает, что и куда он сейчас записывает/читает. Неужели в зенде изначально такой опции нет?
И вот эта строчка смущает:
> $result = $cache->__call($name, $arguments);
Там наверно вызов модели стоит все же. Или я что-то не понял?
Кеш должен ставиться где-то в репозитории/table gateway, так как он знает, что и куда он сейчас записывает/читает. Неужели в зенде изначально такой опции нет?
И вот эта строчка смущает:
> $result = $cache->__call($name, $arguments);
Там наверно вызов модели стоит все же. Или я что-то не понял?
У вас самого нет ощущения явного несовершенства мира
Совершенного мира нет, также как и совершенных систем. Иначе мы бы с вами тут не общались.
$result = $cache->__call($name, $arguments);
Попытаюсь вам объяснить. Класс Zend_Cache_Frontend_Class, который используется в моем примере, устроен так, что для кэширования динамических и статических методов на нужно будет передавать наш объект либо по имени класса 'Default_Models_Products' (для кэширования статики*), либо по ссылке на объект new Default_Models_Products (для кэширования динамики*).
* под статикой и динамикой подразумевается статические и динамические методы
Так вот $cache->__call вызывает магический метод __call того самого класса Zend_Cache_Frontend_Class. А в переменную $cache подставляется либо экземпляр класса созданный для статики, либо экземпляр класса созданный для динамики.
Вот и всё, мой абстрактный класс всего навсего надстройка, созданная для удобства.
>> public function cleanCache()
clean — прилагательное.
правильно clearCache
clean — прилагательное.
правильно clearCache
У нас работает приблизительная шняжка на сайте и с ней было несколько проблем замечено…
— пару раз отмечались corrupted data при сетевых проблемах с memcached
— некоторые дядьки забывали включить нужные классы, потом долго тупили такое __PHP_Incomplete_Class_Name и откуда оно взялось? Случается если кешируются объекты…
— локализация сайта у нас традиционно в базе и на сайте изменения в тексте появляются с довольно большой задержкой (когда кэш обновиться)
— не всегда удобно хранить выборки разной длинны из одной таблицы
Кстати неплохо было бы задавать различное время хранения данных в кеше
— пару раз отмечались corrupted data при сетевых проблемах с memcached
— некоторые дядьки забывали включить нужные классы, потом долго тупили такое __PHP_Incomplete_Class_Name и откуда оно взялось? Случается если кешируются объекты…
— локализация сайта у нас традиционно в базе и на сайте изменения в тексте появляются с довольно большой задержкой (когда кэш обновиться)
— не всегда удобно хранить выборки разной длинны из одной таблицы
Кстати неплохо было бы задавать различное время хранения данных в кеше
Sign up to leave a comment.
Кэшируем модели