Accéder au repository depuis votre entity dans Symfony 2

Spread the love

… C’est impossible. Et oui, moi aussi ça m’a fait un choc.

Pourtant, mon problème initial me semblait particulièrement simple et logique : j’ai une entité User qui possède plusieurs entités Pictures, et je voulais créer une propriété personnalisée User->getAvatar() récupérant une seule entité Picture qui aurait été définie comme « isMain ».

Seulement non. on ne peut pas faire :

<?php // Entity\User
public function getAvatar() {
	return $this->getRepository('UserBundle:Picture')->getUserAvatar($this->id)->getQuery()->getSingleResult();
}

et donc on ne peut pas non plus faire dans twig :

{{ user.avatar }}

… Alors comment allons nous faire ?

Et bien j’aimerai vous dire que c’est simple. Mais ça ne l’ai pas.

Le tutoriel

Il faut créer un service UserManager et une extension twig, en plus bien sûr de notre fonction dans le repository.

Commençons par notre fonction dans le répository PictureRepository :

<?php // Entity\PictureRepository :
public function getUserAvatar($_id) {
	$query = $this->createQueryBuilder('p')
		->where('p.user = :userId')
		->setParameter(':userId', $_id)
		->orderBy('p.isMain', 'DESC') // j'utilise OrderBy dans le cas ou il y aurais effectivement des pictures associée, mais aucune définie comme main
	;

	return $query;
}

Voilà pour la fonction qui va nous permettre de récupérer l’avatar. Remarquez que l’on renvoie seulement la requête, et non son résultat. Cela permet de pouvoir réutiliser la même requête ailleurs si on a besoin d’y ajouter de nouvelles conditions par exemple.

Nous allons maintenant créer le service UserManager qui va se charger d’appeler les fonctions des répositories :

<?php // Entity\UserManager

namespace MyBundle\Entity;

use Doctrine\ORM\EntityManager;
use MyBundle\Entity\User;

class UserManager {

	protected $em;

	public function __construct(EntityManager $em) {
		$this->em = $em;
	}

	/**
	* return Picture is main for user
	* @param MyBundle\Entity\User $user
	* @return MyBundle\Entity\Picture
	*/
	public function getAvatar(User $user) {
		$avatar = $this->em->getRepository('MyBundle:Picture')->getUserAvatar($user->getId())->setMaxResults(1)->getQuery()->getOneOrNullResult();
		return !$avatar ? new Picture() : $avatar;
	}

}

Dans notre service, nous avons donc bien la fonction getAvatar() qui va aller chercher notre méthode getUserAvatar créée plus tôt. Remarquez également que notre constructeur prend en paramètre le manager d’entité de notre application.

Pour cela, il faut informer symfony que notre nouvelle classe UserManager est bien un service :

# MyBundle\Resources\config\services.yml
services
  my_user.user_manager:
    class: MyBundle\Entity\UserManager
    arguments: ["@doctrine.orm.entity_manager"]

Notre classe UserManager sera maintenant accessible dans les autres service et dans vos contrôleurs.

Il ne nous reste plus qu’à créer notre extension twig pour pouvoir accéder à notre objet Avatar dans nos templates :

<?php // MyBundle\Twig

namespace MyBundle\Twig;

use MyBundle\Entity\UserManager;

class UserExtension extends \Twig_Extension {

	protected $manager;

	public function __construct(UserManager $manager) {
		$this->manager = $manager;
	}

	public function getFunctions() {
		return array(
			'avatar' => new \Twig_Function_Method($this, 'avatarFunction'),
		);
	}

	/**
	* Function rendering the avatar Picture object of user
	* @param User $user
	* @return Picture
	*/
	public function avatarFunction($user) {
		return $this->manager->getAvatar($user);
	}

	public function getName() {
		return 'user_extension';
	}

}

Et finallement, on en fait également un service pour que Twig soit informé de cette nouvelle extention :

my_user.user_extension:
  class: MyBundle\Twig\UserExtension
  arguments: ["@my_user.user_manager"]
  tags:
    - { name: twig.extension }

Enfin, notre objet « Avatar » est complètement accessible, y compris dans Twig, et nous pouvons accéder à ses propriétés, comme le chemin vers le fichier image de notre Picture :

<img alt="" src="{{ avatar(user).webpath }}" />

Mes conclusions

Tout d’abord, force est de constater que le code est considérablement alourdi. On choisis d’utiliser un framework comme Symfony pour gagner du temps sur le développement, mais quand on voit ça, on ne peut que ce demander si on y arrive vraiment… On vient d’écrire plus de 30 lignes de code pour une fonction qui en prend normalement 3, et ce dans 4 fichiers différents…

De plus, ça rend également plus complexe la maintenabilité du code… Je n’ose imaginer ce qu’il se passerait si jamais on devait avoir des mises à jours à ce niveau.

Enfin je reviens sur le cœur du problème. Symfony nous impose ce système en prétendant que les entités ne doivent être utilisées uniquement pour représenter strictement le schéma de la base de donnée. Hors sur ce point, on voit qu’ils se contredisent eux-même dans leurs tutoriels en y créant de méthodes personnalisées : http://symfony.com/doc/current/cookbook/doctrine/file_uploads.html.

Quelle est donc la différence entre créer une méthode « getWebPath » et une méthode « getAvatar » qui fait appel à un repository ?

Vous me répondrez peut-être qu’un repository fait appel à la base de donnée via une requête.

Il me semble que c’est pourtant la fonction première d’une entité. Toutes ses propriétés résultent d’un appel à la BDD.

C’est le genre de choses qui étaient tellement simple avec Symfony 1 et qui font de Symfony 2 un véritable enfer.

Note complémentaire

Si ce code est fonctionnel, notez qu’il reste encore un hic : à chaque fois que vous appellerez votre nouvelle fonction avatar(), Doctrine va à nouveau exécuter la même requête, ce qui est inutile. Pour éviter cela, vous pouvez soit utiliser le cache de résultat fourni par Doctrine, soit créer quand même une propriété publique avatar à votre objet user et la remplir lors du premier appel de votre service UserManager->getAvatar().


Mes plus chaleureux remerciement à amenophis du chan #symfony sur IRC qui m’a expliqué le truc 😉


Spread the love

4 réflexions sur « Accéder au repository depuis votre entity dans Symfony 2 »

  1. Trés bon article, juste que je suis pas d’accord avec toi sur la comparaison avec le cookbook de l’upload! La méthode getWebPath() n’ajoute aucune adhérence sur un autre composant donc pas de soucis 😉

    Pressé de lire de nouveaux articles suite à mes conseils 😀

    • Comme je le dis dans mon article, je trouve dommage d’être limité dans les méthodes qu’on peut créer ou non sur les entités. Maintenant, évidemment, on choisi un framework, on fait avec ses avantages et ses limitations 😉

      • Hello Thierry !
        Comment vas-tu depuis le master ?
        Je travaille sur Symfony2 depuis maintenant près d’un an et je suis tombé par hasard sur ton article en cherchant une réponse à ce problème bien récurrent !! Faut dire que quand on fait du MVC on veut déléguer le maximum de code à notre Modèle pour éviter de surcharger les controllers, et ce n’est pas mince affaire…
        J’ai bien lu (mais pas testé) le code de ton article et je comprends ton désarroi, en revanche après des recherches un peu plus approfondies, j’ai trouvé cet article (plus récent que le tien) qui explique parfaitement le pourquoi du comment : http://php-and-symfony.matthiasnoback.nl/2014/05/inject-a-repository-instead-of-an-entity-manager/. Tout a plus de sens !! 😉 A la prochaine.

        • Salut Jérémy !
          Ça va super comme tu le vois, j’espère que c’est pareil de ton côté.
          Pour savoir le pourquoi du comment, la question n’est pas vraiment là dans cet article. J’espère surtout pouvoir aider les personnes qui ont été confrontés à ce problème.
          J’en profite simplement pour critiquer certains choix faits par symfony… Chacun son point de vu et ses besoins. 😉

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

+ 81 = 85