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 ^^

[gilwath]

bah ce que je voulais dire c'est que quand on concevais un bundle il faut pas qu'il mélange et du traitement et de l'interface. vraiment que les bundles d'interfaces face de l'interface et ceux de traitement du traitement. Par exemple dans UserBundle y a des vus par défaut mais c'est pas vraiment le coeur du bundle ( et elles seront vite remplacer par nos implémentations ).

Pour moi dans le cartBundle c'était une bonne idée, car le principe de cadis n'est pas que présente dans les applications d'e-commerces. Pour moi un cadi c'est une collections amélioré, ou tu assigne a chaque objet des attributs supplémentaire (la quantité, le prix dans le cas d'e-commerce, des tags )

[mathieu44800]

Salut,

Suffit de suivre les standards du modéle MVC (Modèle Vue Controller) et de savoir bien modéliser, ne pas injecter du code dans la vue qui ne serait pas à sa place surtout.

Sur ce sujet un très bon article :

http://julien-pauli.developpez.com/t...vc-controleur/

Je ne connais pas personnellement Jean PAULI, mais j'aimerais avoir son niveau...

Cordialement,

Mathieu

[gilwath]

Enfin Symfony2 c'est pas que du MVC, c'est clairement devenus un framework permettant de faire du SOA

[nathieb]

Bonjour,

Clairement les bundles vendors de SF2, sont une extrapolation de ce qui se fait dans d'autres langages, et je pense notamment aux techniques J2EE.
En effet, lors de la conception, on pense packages, donc "services" aux sens intégration de briques logiciels. Cela fait appel à une réflexion amont importante et à une modélisation multicouches (UML), on sépare les besoins.

Le seul hic que je vois, est ce mélange 'pas clair encore', ou un bundle embarque du MVC, qui déroge un peu à la régle des packages. Mais cela semble inhérent au PHP.
J'aurais bien vu des vendors "métiers" et d'autres "IHM".
En tout cas le concept est intéressant. mais un peu tordu pour un novice.

Sinon quelqu'un sait 'il ou je peux trouver la doc pour créer un bundle et l'exporter dans la couche "vendors", je ne trouve pas de lien. Ou j'ai mal compris la doc, il y a un chapitre bundle, mais pas moyen de trouver celui sur "comment faire son bundle et le publier".

Olivier

[winzou]

Uhm je comprends pas trop la question. Pour faire un bundle... tu fais un bundle. Et pour le publier, tu publies le repertoire dans lequel t'as mis ton bundle.

Je vois pas sur quoi tu bloques en fait ?

Sinon c'est vrai que l'idee de separer metier et IHM n'est pas mauvaise. L'avantage avec les bundles c'est que tu peux tout faire. Entre autres, tu peux faire un bundle metier et un bundle IHM Rien ne t'en empeche. Ca complique un peu le truc, mais si c'est interessant dans le cadre de ton appli c'est tout a faire possible

[nathieb]

Bonjour,

En fait je bloque sur la partie, je fais mon bundle générique dans mon "src", voila fait il est prêt.
Par contre, je veux qu'il fonctionne dans la partie "vendor", et c'est la ou je bloque.
Tu fais un copié collé de ton source dans le vendor ?
Je pense qu'il y une procédure, non ?

En fait sur le site symfony2bundles, il n'y a pas d'explication comment font les personnes.


Olivier

[gilwath]

Bah si il marche bien dans le src, il devrais fonctionner dans le vendor, c'est juste une histoire de dossier ( et bien modifier l'autoload pour charger le namespace à partir de vendor aussi )

[winzou]

Comme dit gilwath : si tu donnes ton repertoire Bundle dans ton src a qqn, il va le mettre dans son dossier vendor, et mettre les bonnes valeurs dans autoload.php.

Tout se joue dans autoload.php en fait.

[nathieb]

Bonjour,

Ok pour vos réponses, mais je trouve cela peut clair, voir approximatif.
Mais c'est peut être un pb personnel sdur le respect des conventions.

Olivier

[RapotOR]

Salut,

Pas de procédure!

Toi tu auras dans ton autoload (en prenant Nathieb comme namespace):

Code :

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

1
2
3
4
5
$loader->registerNamespaces(array(
...
    'Nathieb'                         => __DIR__.'/../src',
...
));

alors que les personnes qui utiliserait ton bundle:

Code :

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

1
2
3
4
5
$loader->registerNamespaces(array(
...
    'Nathieb'                         => __DIR__.'/../vendor/bundles',
...
));

Que ton bundle se trouve dans src ou vendor; cela ne change rien au bundle!

[Bakura]

Je me permet d'upper cette conversation qui m'intéresse, afin de partager également mon expérience. Je ne suis pas développeur Symfony mais Zend Framework 2. Pour être honnête, c'est plus ou moins pareil dans la logique, sauf que nos bundles s'appellent des modules (je risque donc de parler de module par réflexe, désolé :o), mais la théorie reste la même, à savoir disposer de briques réutilisables.

Lorsque j'ai commencé mon projet (qui de taille "moyenne" voir "moyen-gros" ), j'y suis allé un peu à l'arrache, puis j'ai décidé de me documenter sur les modules (ou bundles, Symfony 2 étant disponible depuis plus longtemps que ZF 2 c'est justement sur les documentations de Symfony 2 que je me suis renseigné).

Et j'ai tout réécrit, avec comme idée principale de rendre mes modules principaux totalement génériques, que ce soit le module "utilisateur", que la fonctionnalité de "messagerie privée". J'ai passé beaucoup de temps à travailler au maximum avec des interfaces, à utiliser quelques fonctionnalités avancées de Doctrine (notamment le listener "resolve target listener" qui permet de remplacer le nom d'une interface par une classe concrète via un fichier de config).

J'ai viré de ces modules tous les aspects qui étaient liés à mon application grâce aux évènements. Par exemple, dans mon application, lorsqu'un utilisateur créé un nouveau message privé avec un autre utilisateur, je dois envoyer un e-mail au destinataire pour l'avertir.

Concrètement, ma couche service est passée de ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public function createThread(Thread $thread)
{
    // Enregistrement du thread en base
    ...
 
    // Création d'une entité de jointure
    ...
 
    // Envoi du mail
    $this->getMailerService()->sendMail(...);
}

Par quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public function createThread(Thread $thread)
{
    // Enregistrement du thread en base
    ...
 
    // Création d'une entité de jointure
    ...
 
    // Lancement d'un évènement
    $this->events->trigger(__FUNCTION__ . '.post', array('thread' => $thread);
}

C'est grâce à cet évènement que je peux intercepter dans mon code applicatif, et effectivement envoyer le mail. J'ai appliqué cette logique dans tous les modules réutilisables, en n'y intégrant dans les services que les opérations de base, et en me laissant la possibilité d'avoir des "hooks" grâce aux évènements.



Alors, verdict après quelques semaines d'utilisation ? Je pense honnêtement que je perds plus de temps que je n'en gagne. Peut-être ne suis-je pas encore habitué à cette manière de penser mes programmes, ou peut-être que je le fais mal, mais finalement, pour effectivement obtenir un module générique, je dois les écrire avec les fonctionnalités "minimales", et finalement je finis, la plupart du temps, à hériter de ces classes afin d'y ajouter des variables spécifiques à mon code applicatif.

Idem pour les évènements. C'est joli en théorie, en pratique cela se traduit par des fichiers qui récupèrent le event manager pour pouvoir écouter ces évènements, avec du code un peu moche qui vient se greffer ou il peut.

Et ça, c'est quand tout se passe bien. J'ai eu encore un autre cas aujourd'hui. J'utilise un module Utilisateur réutilisable (nous n'avons pas encore de module aussi complexe que FOSUserBundle sous ZF 2, mais nous en avons un plutôt bien fait et complet). Mon designer a souhaité changer la page de login et d'en créer une page dénué de layout, bref, avec une page de login à la présentation bien différente des autres pages du site (avec des raisons recevables que je ne peux pas refuser, et il faut être honnête que c'est plutôt joli).

Ce module offre bien la possibilité surcharger cette vue, et propose même une aide de vue qui n'affiche que le formulaire. Sauf que dans ce cas précis, ma présentation désactive complètement le layout global. Et ça je ne peux tout simplement pas le faire. Du coup, je n'ai eu d'autres choix que : soit modifier directement le code du module générique pour désactiver le layout, ou soit hériter de ce contrôleur pour modifier ce comportement.

Au final, je me suis retrouvé à réécrire une partie de ce module censé être générique dans mon module Application.

Tout ça pour dire que je me rends compte que je perds finalement du temps. Mon code devient moins clair. Pour continuer à garder ce côté générique, j'ai du complexifier largement la plupart de mes modules pour les adapter aux différents cas d'utilisation que je rencontrais au fur et à mesure de mes développements.

Un autre exemple : j'ai besoin dans mon application d'utiliser des données de localisation (ville, adresse, coordonnées...). J'ai donc créé un module "générique" Location contenant des entités ville, adresse... Puis j'ai commencé à écrire le formulaire de création d'une ville... et lorsque je suis arrivé au code postal, je me suis rendu compte dans l'application actuelle, seuls les français peuvent s'inscrire (et vraiment uniquement ceux domiciliés en France). Et la dilemme. Si j'jaoute un validateur pour valider uniquement les codes postaux français dans mon module censé être générique, ça va plus... Donc ce que j'ai du faire, c'est de nouveau lancer un évènement dans la création du formulaire afin de me laisser l'occasion dans mon code applicatif d'écouter cet évènement et de pouvoir y ajouter le validateur correct (ou alors d'hériter de cette classe pour y ajouter le bon validateur, les deux solutions souffrent du même problème, de toute façon).

Et là, je me suis dit : plutôt que d'avoir une solution aussi complexe, n'aurais-je pas gagné du temps à tout simplement faire un module Location au sein de mon application, avec ses propres contraintes ? Et si j'ai besoin de ce module dans un autre projet, je n'ai qu'à le copier/coller, à y supprimer le validateur, et le tour est joué !

Je me suis rendu compte que les seuls endroits ou je pouvais rendre un module parfaitement générique, c'était par exemple pour le bridge avec Doctrine, puisque finalement il s'agit surtout d'étapes de configuration, d'initialisation... qui ne changent pas d'un projet à un autre.

En conclusion de cette expérience, je dirais qu'à l'avenir, dès qu'un de mes modules contient une entité (quelque chose représenté en base), je n'essayerai plus de le rendre totalement générique.

Les modules (ou bundles) me permettent de clairement segmenter mon application, de rassembler mes vues, mes entités, mes contrôleurs... en groupes "logiques" (par exemple, dans mon application, plutôt que d'avoir des modules "PrivateMessaging" ou "JobPost") totalement disctinctes de mon code applicatif et qui m'aurait obligé soit à fournir des hooks un peu partout/complexifier le code pour m'adapter à tous les cas d'utilisations, j'aurai des modules "PrivateMessaging" (mais dont la couche service va directement envoyer le mail, PARCE QUE cette application donné le demande), un module "StudentJob" (et non JobPost, et qui va cette fois-ci assumer qu'il s'agit d'un emploi étudiant parce que mon application le demande)... Et, encore une fois, si un jour j'ai besoin de faire une messagerie privée, je n'aurai qu'à copier/coller, et à ajouter/supprimer les champs et à y adapter ma couche service.

Je ne sais pas ce que vous en pensez...

EDIT : il y a quand même un avantage important aux modules génériques dont j'ai oublié de parler : les tests unitaires. Il est bien plus simple d'écrire des tests sur un module dont on sait qu'il restera fixe sur tous les projets.

[dourouc05]

C'est vrai que tout penser générique, réutilisable, c'est bien en théorie, mais ça prend du temps... en PHP avec Sf2/ZF2 ou en C++ avec boost (ou à peu près tout autre langage) : j'apprécie fortement que la communauté développe des fonctionnalités absolument génériques, que des gars pondent du code magnifiquement conceptuel, horriblement tordu et impossible à comprendre pour un novice, absolument capilotracté et compliqué par endroits pour rien du tout du point de vue de l'utilisateur moyen, mais franchement je n'irai pas pondre ce genre de code tant que le besoin ne s'en fait pas sentir. Si tu as besoin de ton module une seule fois, c'est inutile ; si tu sais que tu vas le réutiliser à chaque application (FOSUserBundle, SonataAdminBundle/AdmingeneratorGeneratorBundle, etc.), là, tu peux y gagner beaucoup.

Je préfère franchement me limiter à faire des bundles bien limités du point de vue fonctionnel (un peu le principe de responsabilité unique, mais étendu aux bundles) : si j'ai jamais besoin de réutiliser une fonctionnalité, je sais que ça existe, je vois le bundle, il suffit de changer le code bien dépendant du projet précédent (aussi peu que possible, mais rien n'est parfait), ça roule. C'est pas magnifique, on ne réutilise pas vraiment du code (si on modifie un bundle, l'autre n'est pas impacté directement), mais on y gagne en nombre de neurones non grillés.

[kiza44]

J'aurais tendance à dire "à chaque bundle son métier". Ceci me permet de me placer au niveau fonctionnel et de raisonner par application :
- user/droits/connexions
- Contacts
- Facturation
- Mails
- etc.
etc...
Il reste ensuite à faire les liens entre bundles dans l'application complète, mais la structure semble cohérente et complémentaire.

[nathieb]

Bonjour,

Je suis professionnel, et ton observation est intéressante.
On en revient toujours au même, si on recherche la pureté du concept c'est satisfaisant, si tu as un client et un budget. C'est toujours une question de calendrier.
Par ailleurs, il faut savoir oublier certains concepts et revenir à l'essentiel.

Exemple : Quand je fais un requête de base avec Doctrine, je dois utilisé trois couches "Doctrine", "PDO",le driver de la base. Est ce toujours pertinent ??

Ces orientations dépendent essentiellement de ce que l'on te demande.

La généricité est parfois l'ennemi du bien ... dans le monde réel.

Olivier