Salut.
J'ai codé aujourd'hui (ou hier vu l'heure) un système de cache de données et je voudrais votre avis là dessus.
Je suis conscient qu'il est encore améliorable et c'est aussi pour ça que je viens vous demandez se que vous en pensez.

--> Explication :
Celui-ci enregistre, sous forme de tableau (array()) encodé en JSON dans un fichier, les données récupérées via SELECT.

Code source: http://wall.deblan.fr/x127/php/1/Systeme-de-cache-de-donnee-dataCache-class-php

--> A l'origine :
Je l'ai fais car je ne voulais pas utiliser un cache de vue (aka enregistrer une page toute entière dans un fichier) car je trouvais cette idée assez galère à utiliser par après.
Il aurait fallu supprimer la vue toute entière après chaque toute petite modification dans le code html, php ou même sur une page où on utilise plusieurs requêtes d'affichage.
Imaginez vous avez une page qui utilise 5 requêtes SELECT, 4 seulement ne changent que rarement tant dis que la 5éme change très souvent.
A chaque SELECT de la 5éme requête les 4 autres sont à refaire aussi alors qu'elles ne sont mises à jours que très peu souvent.

--> Utilisation :
Je l'instancie dans un attribut d'un conteneur (avec d'autres attributs d'autres instances) qui gère mes modèles ainsi quand je dois utiliser un modèle je mets l'instance actuel du conteneur en paramètre.
Ça me permet d'éviter une injection de dépendance.
A l'instanciation de dataCache il faut donner le dossier où sont rangés les fichiers .txt. Je donne ce paramètre au conteneur des managers quand j'instancie celui-ci dans mon contrôleur général (c'est lui qui instancie le bon contrôleur du bon module via un routeur et un dispatcher)

Dans les modèles j'utilise les méthodes dataCache::creer(), dataCache::recuperer(), dataCache::detruire() principalement (il y en a 2 autres comme dataCache::vider() et dataCache::cacheExiste()) quand cela est nécessaire.
Il faut préciser en paramètre à ces méthodes le nom du fichier .txt à utiliser (excepter vider() qui vide tout le dossier d'un coup).
On peut évidement renseigner dynamiquement le nom du fichier style:

$this->modelContainer->dataCache()->detruire('news
-'.$id);

Pour un multi SELECT (aka lister des éléments) il faut écrire ceci:

// Considérez que cette méthode se trouve dans le modèle d'un module de gestion de todo list

public function getListe(){
$todos = array();

if(!$todo = $this->managers->dataCache()->recuperer('todo_list
e')){

$requete = $this->managers->dao()->prepare('SELECT * FROM todos ORDER BY priorite DESC');

$requete->execute();

while($t = $requete->fetch(\PDO::FETCH_ASSOC))
$todo[] = $t;

$this->managers->dataCache()->creer('todo_liste', $todo);
}

foreach($todo as $t)
$todos[] = new Todo($t);

return $todos;
}

Le seul inconvénient pas encore gênant que j'ai trouvé c'est de devoir faire un foreach pour que l'array retourné par la fonction js_decode() de dataCache::recuperer() soit utilisable par la méthode Todo::hydrate().

Voilà si vous avez tout lu, vous êtes des champions et je vous en remercie.

Maintenant -> des avis ? des idées d'améliorations ? (surtout ça le plus important pour moi)

Ah oui à la ligne 8 du code de dataCache, faites pas attention au nom de l'exception lancée, c'est spécifique à mon gestionnaire d'exception.

serialize les données plutôt que de les mettre au format json, tu pourras éviter :
- le problème de mise en cache d'objet
- ne pas avoir des types d'objets en entrée différents qu'en sortie (array, stdClass)

Qui plus est, un cache DOIT avoir une durée de vie, il n'est pas présent dans ton système.

- Je ne récupère que le résultat de la requête que j'insère dans le fichier.
A la sortie la fonction recuperer() renvoie le résultat à l'objet.
Le second paramètre de la fonction json_decode() permet renvoyer le résultat sous forme d'array associatif, donc comme le résultat a été précédemment enregistrer.

Sinon c'est aussi une possibilité d'utiliser serialize()/unserialize(), je vais même peut-être permettre de choisir le format à utiliser dans la configuration.

- Pas besoin, on détruit le cache seulement quand on ajoute/modifie/supprime une entrée.
Je copie/colle l'exemple que j'ai donné:

"Imaginez que vous avez une page qui utilise 5 requêtes SELECT, 4 seulement ne changent que rarement tant dis que la 5éme change très souvent.
A chaque SELECT de la 5éme requête les 4 autres sont à refaire aussi alors qu'elles ne sont mises à jours que très peu souvent. "

Ça veut dire que tant qu'on a pas bougé aux entrées qui correspondent aux résultats des 4 requêtes, les données resteront stockées dans les fichiers txt.

Après rien ne m'empêche de modifier ma fonction recuperer() pour qu'elle vérifie le filemtime() du fichier et renvoie false si celui-ci est périmé. Mais honnêtement je n'en vois que peu d'intérêt vu que la requête sera toujours identique.

ps: merci pour la critique

Ton système de cache DOIT être indépendant des mises à jour des données coté serveur de données. Tu dois absolument gérer une durée de cache, c'est essentiel. Pour avoir travaillé sur de gros projets avec des données à placer en cache, je t'assure que la durée de vie du cache est très importante. Et dans le contexte d'un site, c'est bien plus que des données d'une requête qui va être "caché", mais le rendu final (et on reprends une bonne raison de gérer une durée de vie de cache).

Je vois où tu veux en venir mais imagine une page d'un forum, comment caché ces données pour ne pas utiliser trop de requête SELECT tout en le mettant à jour à chaque fois qu'un utilisateur poste/édite/supprime un message ?

Si tu définis par exemple 5 minutes avant mise à jour d'un fichier cache, tu auras TOUJOURS 5 minutes de décalage à l'affichage.
Alors pour un topic qui reçoit peu souvent de réponse ça peut encore passer, mais un topic populaire tu fais comment ?

tu ne fais pas de cache sur ça, tout simplement. Le cache n'a aucun intérêt sur des données mise à jours souvent.

D'accord.

Autant mettre la Vue en cache alors.

Pas dans le cadre d'un forum en tout cas. Tu pourras traiter les composants autour par contre : les personnes connectées (on est pas à 2 minutes près), certains menus, etc.