Dans ce dernier chapitre je vous propose de revenir sur le problème de performances au niveau de nos requêtes SQL. En effet, on remarque un nombre important de requêtes SQL sur les pages de listing de nos biens avec près de 17 requêtes pour n'afficher que 12 biens. Ce problème est lié à l'utilisation d'un ORM et est appelé le problème n + 1.
Dans notre cas, on demande au système de récupérer les images associées à un bien au niveau de notre vue Twig. L'ORM fait alors une requête supplémentaire pour récupérer ses images et cela pour chaque élément présent dans notre listing. Pour remédier à ce problème il existe plusieurs solutions que l'on va explorer ensemble dans cette vidéo.
Eager loading - 1:40
Le principe de l'eager loading est de charger dès la première requête l'ensemble des informations dont on va avoir besoin. Dans le cas de Doctrine cela peut se gérer au niveau de la définition de l'association ou en faisant un Left Join au niveau de notre requête. Cette solution permet alors de récupérer l'ensemble des informations en une seule fois et l'hydratation va automatiquement remplir nos entités comme attendu. Cette méthode est la plus simple mais elle peut avoir comme effet indésirable de générer des requêtes SQL qui renvoie beaucoup trop de lignes (ce qui ralentira le processus d'hydratation et qui demandera plus de mémoire).
Le fragment caching - 5:30
Une autre solution consiste à contourner le problème en mettant en cache certains bloc de nos vues. Par exemple, il est possible de mettre en cache le bloc HTML qui représente notre bien. Ainsi lors du second affichag, le code qui permet de récupérer les informations associées à notre bien ne sera pas éxécuté et la requête supplémentaire ne sera pas faite. Cette méthode est aussi appelé le Russian doll caching.
Hydratation manuelle - 11:45
Enfin, une dernière solution consiste tout simplement à gérer manuellement l'hydratation des informations nécessaires lors de notre affichage. Dans notre cas, on va faire une requête séparée afin de récupérer les images associées à un bien. On utilisera ensuite manuellement les setters afin de remplir d'associer cette image dans notre entité Property.
C'est la méthode qui demande le plus d'efforts mais qui permet d'avoir le plus de contrôle sur l'hydratation des données associées.
