Discussion :

[khand]

Bonjour à tous,

J'aurais voulu avoir votre avis concernant le concept de BUNDLES. Etes vous d'accord avec les affirmations suivantes :

• Un bundle ne devrait contenir que des classes abstraites et interfaces.
• Un projet Symonfy, est composé d'un bundle SiteBundle qui contient la partie propre au projet, et d'autres bundles qui sont eux entièrement indépendant du projet et qui apportent des fonctionnalité génériques.
• Dans un bundle bien pensé, on ne devrait pas retrouver d'implémentation directe du CRUD.

Avez vous des bonnes adresses concernant la généricité des bundles, et les bonnes pratique à appliquer au niveau architecture ? (en dehors de cette adresse)

Merci, bonne journée et joyeuse saint valentin

[spike2]

Si tu veux faire un bundle qui ne sera pas destiné à être partagé, par exemple sur github, tu peux très bien faire des crud dedans, dont les controllers étendent le FrameWorkBundle/Controller/Controller. Par contre si tu souhaites le mettre à disposition d'autres personnes, il est conseillé de déclarer les contrôleurs en tant que service.

L'autre point c'est que tu parles de classe abstraite et d'interface. Pourquoi ? Ca n'est pas important qu'il y en ait ou pas, c'est des notions de conceptions objet, pas de Symfony2.

Le dernier point est que oui tu peux avoir un bundle SiteBundle qui peut regrouper par exemple le layout de base et les css etc.

J'espère que ça réponds à tes interrogations

[pc.bertineau]

Un bundle ne devrait contenir que des classes abstraites et interfaces.

Pas du tout, tu comptes les mettre où tes classes finales de toute façon ?

[khand]

Bonjour,

Merci pour vos réponses.

Pas du tout, tu comptes les mettre où tes classes finales de toute façon ?

Je comptais les mettre dans un autre bundle qui hériterait de mon bundle générique. En procédant de la même manière que lorsque l'on hérite du bundle public FosUserBundle.

Du coup je me pose un autre question : est-ce que chaque bundle que l'on créé pour un projet, doit être pensé comme pouvant être public ? Et donc le rendre totalement indépendant du projet.

Ce qui m'ennuie, c'est que actuellement mes bundles sont des genres de "package" (au sens Java) qui sont absolument pas réutilisables. Pourtant c'est bien la première utilité et raison d'être des bundles : la réutilisabilité !

Et vous comment pensez vous vos bundles ? Les réutilisez vous de projet en projet ?

Merci à tous.

Bonne soirée !

[pc.bertineau]

L'idéal est de rendre chaque bundle indépendant. Mais le mieux est parfois l'ennemi du bien...

En pratique, mon (gros) projet actuel comprend un bundle "coeur" + 4 bundles correspondant à des fonctionnalités indispensables. Le bundle coeur est indépendant, il contient les entités de mon projets, les sevrices transverses, ... Les autres bundles indispensables dépendent du coeur, et peuvent dépendre les uns des autres.

[khand]

Mais donc, tu n'as aucun bundle vraiment indépendant du contexte de ton projet qui pourrait être réutilisable dans un autre projet ?!

Merci !

[pc.bertineau]

Si, j'ai des bundles supplémentaires, qui apportent une fonctionnalité technique, ceux là sont totalement indépendant.
Mais un bundle basé sur une fonctionnalité métier, pas encore.

Mon appli gère des commandes, un inventaire, un compte user et des préférences. Mes bundles Inventory et Order sont dépendants de mon bundle "coeur", et du bundle Preferences. Ce sont des fonctionnalités dites indispensable à mon appli, ils ne sortiront jamais du projet.

Mais si je veux ajouter une fonctionnalité Catalog, celui-ci, je le ferai totalement indépendant.

Pour résumer, ça dépend beaucoup du découpage que tu fais. Si tu sais déjà que as des briques fonctionnelles que tu aimerais utiliser autre part, isole les dès le début (et inclus-y les entités propres à cette fonctionnalité).