2010-08-16 4 views
0

J'utilise Stacic Page Cache (avec cache action helper) pour mettre en cache la plupart des pages de mon application.
Ceci est extrêmement rapide, mais pas toujours adapté.ZF - Comment mettre en cache des parties de la mise en page

  • Comment mettre en cache-vous des pages avec des données dynamiques? Par exemple. La mise en page contient des informations spécifiques à l'utilisateur.

Une solution que j'ai envisagée consiste à charger des données supplémentaires via Ajax. Mais dans mon cas, il serait préférable de mettre en cache certaines parties des pages (par exemple, une liste d'entrées ou une partie de la barre latérale).

  • Existe-t-il une méthode recommandée par ZF pour le faire? Par exemple. cache la vue uniquement, pas la mise en page ou vice versa.

L'aide d'action de cache fournit une interface agréable pour mettre en cache toutes les actions. Toute solution pour mettre en cache le contenu de la page ou les partiels ou afficher les helpers?

Répondre

0

Ce que j'ai fait récemment est la création d'un service, puis la configuration de ce service avec une connexion db et un objet cache. Récupérer les données utilise une sorte de "cascade de chargement paresseux", regardant d'abord en mémoire, puis en cache, puis à la base de données. Par exemple, une de mes applications est pour une agence immobilière qui opère dans plusieurs - mais pas toutes - des provinces dans notre pays. Nous avons une table de db de provinces, dont certaines sont activées pour le front-end, et nous devons les rendre à divers endroits (disons, en tant qu'options dans un élément sélectionné). Nous faisons quelque chose comme ça (l'héritage de code base sur laquelle je travaille utilise objets DAO pour l'accès db et la Cache_Lite de PEAR pour la mise en cache, de sorte que l'exemple n'est pas strictement Zend Framework, mais le principe est tout aussi):

/** 
* A service for fetching provinces 
*/ 
class My_Service_Provinces 
{ 
    protected $_daoProvinces; 
    protected $_provinces = array(); 
    protected $_cache; 


    public function __construct($daoProvinces) 
    { 
     $this->setDaoProvinces($daoProvinces); 
    } 

    public function setDaoProvinces($daoProvinces) 
    { 
     $this->_daoProvinces = $daoProvinces; 
     return $this; 
    } 

    public function getDaoProvinces() 
    { 
     return $this->_daoProvinces; 
    } 

    public function setCache($cache) 
    { 
     $this->_cache = $cache; 
     return $this; 
    } 

    public function getCache() 
    { 
     if (null == $this->_cache){ 
      $this->_cache = new My_Cache_Provinces(); 
     } 
     return $this->_cache; 
    } 

    public function getProvinces() 
    { 
     if (null == $this->_provinces){ 
      $cache = $this->getCache(); 
      $data = $cache->get(); 
      if (!$data){ 
       $dao = $this->getDaoProvinces(); 
       $rows = $dao->frontend(); 
       $data = array(); 
       while ($row = $rows->get_row()){ 
        $data[$row['provinceId']] = $row; 
       } 
       $cache->save(serialize($data)); 
      } else { 
       $data = unserialize($data); 
      } 
      $this->_provinces = $data; 
     } 
     return $this->_provinces; 
    } 

    public function getProvince($provinceId) 
    { 
     $provinces = $this->getProvinces(); 
     return isset($provinces[$provinceId]) ? $provinces[$provinceId] : null; 
    } 
} 

L'objet cache est préconfiguré avec la durée de vie appropriée. Je donne une longue vie à des données qui changent rarement, des durées de vie plus courtes à des données qui changent fréquemment. Si j'ai vraiment besoin que la modification des données soit immédiatement disponible pour l'application - disons, l'administrateur ajoute une nouvelle province - j'instancie l'objet cache et efface le cache à la mise à jour.

J'ai même ajouté une fabrique pour aider à instancier le service afin que le code d'appel ne doive pas transpirer les dépendances. code d'appel - peut-être dans un contrôleur ou même dans une vue ou vue helper - ressemble à quelque chose comme:

$service = My_Service_Factory::getService('provinces'); 
$provinces = $service->getProvinces(); 

Knowwhatimsayin'?

+0

Merci. C'est plutôt évident. Mais en lisant votre article, j'ai eu l'idée de 'My_View_Helper_Cached_Abstract' ou' My_Service_Abstract :: setCache ($ cache, $ lifetime) '. Qu'est-ce que tu penses? Comment configurer la ressource de cache dans le fichier application.ini alors? – takeshin

+0

Oui, c'est plutôt évident. ;-) Pour le contenu non lié à la demande de la page "de base" - mise en page, comme les encadrés - j'aime votre approche d'aide à la visualisation. L'assistant d'affichage appelle le service qui utilise la mise en cache. Votre idée d'ajouter une durée de vie configurable dans le cache semble vraiment bonne. Mais l'objet cache lui-même n'a-t-il pas une durée de vie "cuite" comme l'une des options de l'interface? Je vois donc une signature de méthode de la forme 'My_Service_Astract :: setCacheLifetime ($ lifetime)'. Ensuite, des sous-classes de service spécifiques peuvent utiliser différentes durées de vie lorsqu'elles instancient lazy-instance de l'objet de cache. –

+0

En fait dans la plupart des cas '$ lifetime' sera infini. Le paramètre le plus important est '$ cachetag', à effacer à la demande. – takeshin

Questions connexes