Кэшируем модели

[josser]

Я пока еще не дочитал, но вот первый вопрос такой: для чего сделаны врапперы над __call, __callStatic и __construct?

[tolyjan]

__construct нужен для инициализации параметров класса модели, которая наследуется от абстрактного. А __call и __callStatic нужны для вызова динамических и статических методов. Всё описание в статье.

[mr_avi]

«Магия» — не очень хорошо, я бы сделал иначе:
Простенький генератор моделей (должно быть, наверняка, что-то готовое), который сгенерит (перегенерит) все методы для всех полей с учётом кеширования, в т.ч. и через мемкешы, редисы,etc.

[Yeah]

Метод неплох, но есть несколько замечаний:
1. Инициализация кэша не должна выполняться внутри данного класса. У ZF для этого есть bootstrap и конфиг. Лучше сделать статические методы getCache и setCache, которые бы запускались из bootstrap.
2. Было бы неплохо указать, что этот класс работает только в PHP 5.3

[tolyjan]

Спасибо за замечания. Инициализацию кэша действительно можно вынести, в моем классе показана идея для понимания что именно мы делаем и про какие вещи не стоит забывать. По поводу версии php 5.3 я внес правки в статью.

[dmitry_dvp]

>> Лучше сделать статические методы getCache и setCache, которые бы запускались из bootstrap.
уточнил бы, что лучше сделать статические методы getDefaultCache setDefaultCache и нестатические getCache и setCache

[dmitry_dvp]

А разве родной frontend class не тоже самое делает?

[dmitry_dvp]

виноват, не разглядел, что в статье как раз именно над этим надстройка

[egorinsk]

Проксирование вызовов методов модели тут выглядит как уродливый костыль. Также, с вашим кодом надо создавать мусорный класс к каждой модели. а еще не забыть перечислять все модифицирующие методы как некешируемые. У вас самого нет ощущения явного несовершенства мира^W получившейся системы?

Кеш должен ставиться где-то в репозитории/table gateway, так как он знает, что и куда он сейчас записывает/читает. Неужели в зенде изначально такой опции нет?

И вот эта строчка смущает:

> $result = $cache->__call($name, $arguments);

Там наверно вызов модели стоит все же. Или я что-то не понял?

[tolyjan]

У вас самого нет ощущения явного несовершенства мира

Совершенного мира нет, также как и совершенных систем. Иначе мы бы с вами тут не общались.

$result = $cache->__call($name, $arguments);

Попытаюсь вам объяснить. Класс Zend_Cache_Frontend_Class, который используется в моем примере, устроен так, что для кэширования динамических и статических методов на нужно будет передавать наш объект либо по имени класса 'Default_Models_Products' (для кэширования статики*), либо по ссылке на объект new Default_Models_Products (для кэширования динамики*).
* под статикой и динамикой подразумевается статические и динамические методы
Так вот $cache->__call вызывает магический метод __call того самого класса Zend_Cache_Frontend_Class. А в переменную $cache подставляется либо экземпляр класса созданный для статики, либо экземпляр класса созданный для динамики.
Вот и всё, мой абстрактный класс всего навсего надстройка, созданная для удобства.

[dmitry_dvp]

>> public function cleanCache()
clean — прилагательное.
правильно clearCache

[dmitry_dvp]

хм… фейл. Zend тоже пишет clean. Удивлён

[chiffa_ua]

clean & clear — это почти синонимы, и глаголы тоже.

[chiffa_ua]

У нас работает приблизительная шняжка на сайте и с ней было несколько проблем замечено…

— пару раз отмечались corrupted data при сетевых проблемах с memcached
— некоторые дядьки забывали включить нужные классы, потом долго тупили такое __PHP_Incomplete_Class_Name и откуда оно взялось? Случается если кешируются объекты…
— локализация сайта у нас традиционно в базе и на сайте изменения в тексте появляются с довольно большой задержкой (когда кэш обновиться)
— не всегда удобно хранить выборки разной длинны из одной таблицы

Кстати неплохо было бы задавать различное время хранения данных в кеше

[tolyjan]

За время хранения кэша отвечает параметр 'lifetime', который надо передать в frontendOptions сделать это можно тем же способом как выполнена передача 'non_cached_methods'.