Discussion :

[winzou]

Salut a tous,

Souvenez-vous, on avait eu une discussion du type : a quel niveau decouper nos applications en bundles ? On etait plus ou moins d'accord qu'il etait bon de decouper assez petit pour pouvoir tout reutiliser.

Maintenant qu'on a plus d'experience (je sais pas si vous avez beaucoup code depuis, moi un peu), j'aimerais reavoir votre avis.

Car de mon cote... je trouve que decouper petit est vraiment chiant ! C'est tres lourd (surtout des que des entites et des jointures interviennent), et l'interet est finalement tres faible. On arrive a un point ou il est aussi facile pour un developpeur final d'ecrire le code soi-meme, directement integre a son application, que d'heriter d'un bundle exterieur, et de l'integrer a son application.

Developper un bundle generique, ca ne demande pas les memes methodes que developper un bundle a soi. Interet du bundle mis a part, il faut vraiment prevoir beaucoup de choses en plus par rapport a faire du code maison... sinon votre bundle n'est pas si generique que ca et vous etes le seul a l'utiliser.

Aujourd'hui je me tourne vers le choix suivant : continuer de decouper mon application en bundles, mais faire des bundles pas trop petits, et ne meme pas essayer de les faire generiques. J'aurais donc des bundles avec de grosses dependances (utilisateurs, differentes jointures internes, etc), mais qui resteront bundles (donc separation du repertoire Resources notamment).

Ou en etes vous dans cette reflexion ? Est-ce que vous y voyez plus clair dans cette notion de bundle ?

[RapotOR]

Je comprends... et je crois qu'il n'y a pas vraiment de bonnes ou moins bonnes solutions. Feeling; quitte a faire des erreurs.

Rendre les bundles purement génériques prend un temps bète.

Je crois que ce n'est pas nécessaire si le but premier n est pas de le vouer a être purement public; Le faire si le but n'est pas une application mais le but est le bundle lui-même! Et meme dans ce cas, comme Rome ne s'est pas fait en un jour; il est peut être bon d'y aller step by step.

Pour ce qui est des bundles a réutiliser soi-même.
Il est peut être possible de rendre générique au besoin; de modifier le bundle si le multi-usage s'avère nécessaire avec le temps. Ceci en faisant peser la modification avec le fait de "repartir de zero"... mais les tests unitaires vont être bien utiles!

Qu'en penses tu?

[rica1503]

Bonjour,

Je suis d'accord pour dire que cela dépend des intentions de l'application et du type de bundle. En effet, si l'objectif est de développer une application publique pouvant être personnalisée par la suite, mieux vaut qu'elle soit créée à partir de bundles le plus génériques possibles, auquel cas, personne ne l'utilisera.

A l'échelle du bundle, si son rôle n'est pas trop lié à l'application et qu'il semble pouvoir être utilisé ailleurs, le développer de manière générique est un investissement. Par exemple, j'ai développé pour mon application un bundle générique Category alors que je n'ai besoin que d'une catégorie d'articles car je me dis que je pourrais avoir besoin de faire une catégorie d'autre chose un jour...

Voilà mon avis...

[mathieu44800]

Salut,

Je pense qu'il faut vraiment étudier via une méthodologie particulière ce genre de choses.

En effet, ces "Bundles" me font penser à ce qu'un architecte que j'ai connu appelait "Packages" en UML.

Je vous conseilles de bien modéliser vos application web avant de développer des couches et des couches, qui potentionnellement, ne pourrant pas ou peu dialoguer entre elles.

Pour bien pouvoir dialoguer en UML, je vous conseille un vieux bouquin (peu être), pour l'avoir parcouru afin de comprendre de quoi je parlais :

http://web.developpez.com/livres/dev...L9782212121360

Dans son genre, je crois que Pascal ROQUES n'a plus rien à prouver, j'aimerais bien travailler avec lui, d'ailleurs !!!

Cordialement,

Mathieu

[gilwath]

C'est la question qu'on se pose actuellement d'ailleurs, comment découper nos futures applications, et y a pas vraiment de bonne solution, si on veut une bonne ré-utilisabilité il faut penser à être le plus générique possible et pas implémenter dans ces bundles réutilisable a des choses qui sont purement spécifique à une application. Perso déjà je pense qu'il faut clairement séparé les bundles qui concerne l'interface et les bundles qui concerne les traitements serveurs.

[spike2]

Diviser pour régner, mais pas trop ! Sinon ça marche plus.
Pour ma part en ce moment je découpe suivant ce que j'ai à gérer et que je pense que je vais réutiliser plus tard. Exemple j'avais continué à jouer avec la gestion d'un utilisateur et son panier d'achats, il m'est apparu, ou plutôt "nous" est apparu (voir sujet sur le cartBundle ^^) que si on cherche à vouloir trop découper l'application - ici on voulait juste gérer le panier sans parler d'utilisateur ni des produits - finalement ça ne servait plus à rien.

Mais je reste quand même dans l'optique de réutilisabilité du code et de ses changements. L'utilisation de l'injection de dépendances n'est pas non plus à voir comme difficile, lourde ou inutile.

Les bundles qui devraient être génériques seraient ceux qui se répètent souvent sur un site: utilisateur, forum, backend, commentaires, newsletter, fluxrss etc...tout ça va être proposés par la communauté. Le reste repose sur votre conception UML comme l'a dit Mathieu44800 et ensuite on pioche à droite à gauche les éléments qu'on a déjà en stock pour bâtir le reste du site.

Perso déjà je pense qu'il faut clairement séparé les bundles qui concerne l'interface et les bundles qui concerne les traitements serveurs.

Qu'est-ce que tu veux dire par là ? Si je prends un bundle de pagination par exemple, ou UserBundle, les deux sont liés. Ou c'est pas ça que tu veux dire ^^