Discussion :

[vinmar]

Bonjour,

Je me tourne vers la communauté sur un point d'organisation d'un bundle. Au cours de mes travaux sur Symfony2, je me suis créé un bundle qui rassemble tout ce qu'il faut pour créer un carnet d'adresses. Ce bundle embarque comme vous pouvez l'imaginer un ensemble d'entités : des contacts, des adresses, etc.

Mon objectif était de le rendre complétement indépendant afin de l'utiliser dans n'importe quel projet Symfony2 et j'en ai fait un "vendor". Comme ça un petit composer require et hop, il est installé.

Actuellement, après avoir lancé la commande de mise à jour du schema avec Doctrine (doctrine:schema:update) j'installe toutes les entités. Cependant, je me pose la question suivante : est-ce qu'il est préférable de garder la persistance des entités dans mon bundle "vendor" ou de déporter la persistance des ces dernières dans un bundle spécifique au projet Symfony dans lequel il est installé ?

FOSUserBundle par exemple n'embarque que des mapped-superclass, la persistance de l'entité User se faisant dans un bundle héritant de ce dernier. Le truc c'est que mon bundle comporte des entités qui sont beaucoup plus liées entre elles qu'une simple entité dans son coin. De plus les mapped-superclass ne peuvent comporter que des relations many-to-many alors que mes entités on d'autres types de relations. Ce qui veut dire pour moi que les fichiers mapped-superclass ne serait que d'une utilité limitée (ne pouvant comporter qu'une petite partie de la définition de mes entités). Il faudrait donc déporter toutes les entités dans le bundle héritant de mon "vendor" à chaque fois que je l'utilise. Quelles sont les bonnes pratiques en la matière ?

Merci d'avance de vos retours.

[arnooo999]

Bonjour

Ce lien devrait pouvoir t'aider:

Avec le ResolveTargetEntityListener, vous êtes capable de découpler vos bundles, en les gardant utilisables par eux-mêmes, mais en étant toujours capable de définir des relations entre différents objets.

http://symfony.com/fr/doc/current/co...et_entity.html

[vinmar]

Bonjour

Ce lien devrait pouvoir t'aider:

http://symfony.com/fr/doc/current/co...et_entity.html

Ça je l'ai. D'ailleurs, c'est justement ça qui me fait poser plein de question. Explication (ça peut servir à tous) :

J'utilise le resolve_target_entities que je trouve super pratique pour faire pointer une relation entre deux entités dans deux bundles différents non pas directement vers l'entité cible mais vers une interface qui se "substitue" à l'entité cible. C'est-à-dire par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
<?xml ?><?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                  xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
                  http://doctrine-project.org/schemas/orm/doctrine-mapping.xsd">
 
    <entity name="Acme\Bundle\AddressBookBundle\Entity\Person" inheritance-type="JOINED" table="person">
 
	 <one-to-one field="account" target-entity="Acme\Bundle\AddressBookBundle\Model\Person\PersonAccountInterface">
        	<join-column name="account_id" referenced-column-name="id" />
        	<cascade>
        		<cascade-persist />
        		<cascade-remove />
        	</cascade>
        </one-to-one>
 
    </entity>

Comme vous pouvez le constater, on fait pointer la relation sur PersonAccountInterface qui n'est pas une entité. Ensuite dans le fichier de config :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
# app/config/config.yml
doctrine:
    orm:
        resolve_target_entities:
            Acme\Bundle\AddressBookBundle\Model\Person\PersonAccountInterface: Acme\Bundle\UserBundle\Entity\User

That's rocks !

Mais, que ce passe-t-il si le bundle UserBundle n'est pas installé ? Bah, y'a un bug parce qu'il va chercher quand même à faire la relation. Puis j'ai trouvé cette solution :

http://stackoverflow.com/questions/1...s-in-symfony-2

En gros, elle remplace le listenener resolve_target_entities et rajoute une petite ligne pour ignorer la relation si l'entité cible (ici Acme\Bundle\UserBundle\Entity\User) n'existe pas.

Ca marche nickel mais je me dis demain, je met à jour mon Smyfony et ce listener change. Il faut donc que je change mon listener de substitution aussi. C'est pas très propre mais je suis quand même parti sur cette solution qui, je trouve, est plutôt pratique quand on fait des bundles "vendor".

Ma réflexion finale est que je suis super content mais est-ce que je prend la bonne route ? La bonne pratique ne passe t'elle pas par : ne pas persister les entités dans mon bundle "vendor" et laisser cette persistance dans un bundle qui en hérite => plus de boulot car à chaque fois il faut créer les entités dans le bundle fils mais peut-être plus propre... ou pas.

[Nico_F]

Hello,

Voilà comment je fonctionne : pas d'entité dans le bundle, pas de mapping non plus. Le mapping est propre à l'application (métier).
Uniquement des interfaces, et ensuite les méthodes appelées par les différents services sont présents dans l'interface.

Avec un petit aperçu de ton model on pourrait peut-être te guider un peu mieux aussi.

[vinmar]

Hello,

Voilà comment je fonctionne : pas d'entité dans le bundle, pas de mapping non plus. Le mapping est propre à l'application (métier).
Uniquement des interfaces, et ensuite les méthodes appelées par les différents services sont présents dans l'interface.

Avec un petit aperçu de ton model on pourrait peut-être te guider un peu mieux aussi.

Merci. Après réflexion, je suis d'accord avec cela. Mon objectif était de me simplifier le vie en transformant des bundles que j'avais développé dans "src" et de les transformer en "vendor" pour les installer via composer dans d'autres projets.

Je cherchais le juste milieu entre l'installation d'un bundle qui me rajoute une fonctionnalité "telle qu'elle" (out of the box, comme dirait l'autre) et l'installation d'un bundle qui demande un peu plus de travail.

Au bout du compte, je me suis dit que le "out of the box" n'est pas une bonne façon de réfléchir parce que :
1. tu auras souvent (voir toujours) des relations entre les entités qui sont liées à la logique métier de ton application.
2. En regardant la structure des bundles reconnus (type FOSUserbundle), un bundle vendor doit apporter un modèle à adapter, non un modèle figé.

Je passe donc par des interfaces.

Pour aller plus loin, que pensez vous des mapped-superclass ? Les utilisez-vous ?

[Nico_F]

Jamais utilisé, et j'avoue ne jamais m'être penché plus que ça dessus, mais si j'ai bien compris, les infos de mapping d'une classe sont déjà définies dans sa classe parent et ça, ça ne m'enchante pas trop.

Pour le moment je n'ai pas rencontré de situation ou un Single Table Inheritance ne suffisait pas.