Discussion :

[JackStrieger]

Bonjour,

J'ai un peu de mal avec la structure de Symfony 2 et je voudrais votre avis ou savoir comment vous faites avec les entités.

Admettons qu'on ait une table posts, et on y accède dans 2 bundles : Bundle Admin et Bundle View

Pour l'instant je déclare une classe entité dans le bundle admin que je réutilise dans le bundle view. Mais avec plusieurs tables c'est de moins en moins intuitif, et j'aimerais savoir comment vous faites.

Est-il possible d'avoir plusieurs classes entités pour une même table ?
Comment séparez vous les classes les bundles (accéder à posts par l'entité du bundle admin, et inversement je suis pas sur que ça soit bien)

Je pense avoir raté quelque chose à ce niveau dans la doc, merci de bien vouloir m'éclairer !

[Tsilefy]

Du moment que tu déclares la dépendance dans le composer.json de la bundle view, je ne vois pas de souci.

Je conseillerais de faire hériter l'entité de bundle view de l'entité de bundle admin (ou de créer une classe-mère commune aux deux, selon les cas).

[JackStrieger]

Merci pour ta réponse.

Ce n'est pas réellement un "problème", mais ça me dérange plus dans la conception d'un projet. Ce serait plus logique (pour moi), que view récupère ses entités de son propre bundle, même si ça fait du code redondant. Si quelqu'un reprend le projet, dans le cadre d'un gros projet, on peut penser que c'est mal structuré.

Ta solution de créer une classe mère commune me paraît bonne. Dans ce cas, tu la placerait où ?

Et de manière générale, si on veut faire une lib, on peut la placer où ?

Merci !

[JackStrieger]

D'ailleurs, je ne mets pas à jour le composer.json... Ca pose problème ? Enfin de manière générale je n'utilise pas du tout composer

[Tsilefy]

Réponses dans le désordre:
- Je parlais du composer.json de ton bundle au cas où tu distribues ton bundle par la suite afin que la dépendance soit vérifiée/installée automatiquement. Rien ne t'oblige à faire cela, mais tu as intérêt à noter cette dépendance quelque part sinon gare à l'oubli.

- Composer est un de ces outils dont on n'a pas vraiment besoin tant qu'on ne l'utilise pas. Une fois qu'on l'a, on a du mal à s'en passer.

- le plus simple est de faire comme tu le fais: utiliser directement les entities dans un autre bundle. Les entities sont des classes comme les autres, il n'y a pas de raison de s'en priver. Si tu veux faire de l'héritage, ce sera un peu plus compliqué (voir http://docs.doctrine-project.org/en/...e-mapping.html pour les différentes manières de le faire, et regarde comme SonataUserBundle et FOSUserBundle le font concrètement).

- tu mets tes libs, comme tout le reste, dans un Bundle, bien sûr.

[JackStrieger]

Merci pour ta réponse ! J'avance j'avance.

J'ai une autre question, je sais pas si j'ouvre un autre poste ! Enfin voilà, dans la classe des entités, je ne peux mettre que des getters et des setters pour doctrine si j'ai bien compris.

Hors je voudrais alléger mes controlleurs. Est-il possible de déclarer des méthodes custom, comme des jointures dans un autre fichier ?

J'ai essayé de faire un dossier Model dans mon bundle, avec une classe héritant de mon entité, et qui est appelée dans le controlleur, mais j'ai un souci pour récupérer le service doctrine, n'étant plus dans le projet... Il y a t'il une méthode correcte de rajouter ces méthodes précises ? Et plus globalement, il y a t'il un moyen de rajouter des classes lib à un projet qui soient plus custom ?

[Tsilefy]

Regarde du côté des classes Repository, c'est exactement ce qu'il te faut.

[JackStrieger]

Merci !