Discussion :

[ozack]

Bonjour,

Je me demande comment organiser mon code... En effet j'ai deux bundle qui manipulent les mêmes entités. De fait ou les placer... ?
DAns un bundle du style LibBundle et par la suite dispatcher le code généré à l'aider des commandes crud par exemple dans le bundle concerné... ?
Comment faites vous ?

Par avance merci

[dukoid]

pourquoi avoir 2 bundle ?

[ozack]

Bon je plaisante... En fait je voulais séparer le code de mon backoffice d'avec le code du front office. Tout simplement parce que le backoffice manipulera des entités qui lui sont propres mais également des entités du front office. L'inverse n'étant pas vrai !
Je dis des bêtises ?

[dukoid]

pour moi :
- si il n'y a pas de raison technique genre le back sur un serveur et le front sur un autre serveur
- si le back ou le front ne sont pas chacune une fonctionnalité que tu va utiliser dans d'autres applications/projets

si ces 2 conditions sont réunis alors un seul bundle suffit.


dans un même bundle, je classe de cette façon :
1 controlleurBack
1 controlleurFront

View/back/.... mes vues
View/front/... mes vues

routing_back.yml
routing_front.yml


après tout est possible, chacun à ses préférences

[pc.bertineau]

Perso je sépare également en 2 bundles. Les entités communes (utilisées dans le Front) vont de le FrontBundle, les entités spécifiques au Back vont dans le BackBundle.

[dukoid]

bertineau, ok et tu fais comment si tu as des entités communes aux 2(back et front) ?

si il n'y a pas de raison particulière je ne vois pas l’intérêt de faire 2 bundles alors qu'il accède tout 2 aux mêmes entités.

[ozack]

Tous les points de vue se défendent. Je débute avec Symfony et si je comprends, le bundle qui d'isoler les fonctionnalités (ex: FOSUserBundle). Dans ce sens il me semblait judicieux d'isoler le backoffice du front office... et même de créer un LibBundle dans lequel je placerai les entités à l'intersection des deux espaces.
Ce qui permet, le cas échéant, de réutiliser... concept cher aux informaticiens !
J'avais commencé de cette façon... pour finalement tout placer au sein du même bundle parce que, paradoxalement, c'est plus simple à gérer...

[Nico_F]

bertineau, ok et tu fais comment si tu as des entités communes aux 2(back et front) ?

si il n'y a pas de raison particulière je ne vois pas l’intérêt de faire 2 bundles alors qu'il accède tout 2 aux mêmes entités.

Tu soulèves un point intéressant : s'agira-t-il vraiment des mêmes entités en front et en back ? Pas sûr : les entités peuvent être radicalement différentes dans différents bundles tout en étant mappées sur la même table en BDD.

Il m'est déja arrivé dans des projets d'avoir une entité A avec des attributs, méthodes, validateurs, LifecycleEvents différents dans le front et dans le back.
Il est alors bien pratique d'avoir une entité A légère et "classique" dans le front (en admettant que l'on n'ait besoin que de 4 ou 5 attributs et accesseurs dans le front), tandis que dans le back, on aura des dizaines d'attributs, méthodes, règles de validation, hooks doctrine etc. qui n'auraient rien à faire dans l'entité que l'on manipule dans le front.
Si c'est son cas, il est alors peut-être plus judicieux de faire deux entités différentes.

Je suis également de ceux qui séparent souvent front et back dans deux bundles différents ne serait-ce que pour la raison que je viens de citer.

[dukoid]

nico_f, pas pensé à des attributs propres aux fronts et back.

donc en résumé, histoire de conclure sur ce point philosophique

séparer le back et le front dans 2 bundles dans l'un de ces cas :
- le front sur un serveur et le back sur un autre serveur
- la re-utisabilité : reutiliser le back et/ou front dans un autre projet.
- dans les entités, avoir des entités avec des attributs perso pour le back et d'autres pour le front. (par exemple avoir des attributs stats dans le back mais pas dans le front car inutile)

[pc.bertineau]

Dans mon applicatif back, je mappe les entités de mes 2 bundles, les communes du FrontBundle, et les spécifiques du BackBundle.

Su rl'applicatif Front, je ne mappe que les entités du FrontBundle...

Surcharger les entités du FrontBundle dans le BackBundle avec des attributs supplémentaires est une excellente idée mais qui demande pas mal de gymnastique. En pratique, je rajoute les attributs dont je n'ai besoin que dans le back directement dans le FrontBundle, et je fais gaffe

[Nico_F]

Je ne suggérais pas vraiment de "surcharger" l'entité du front dans le back, mais plutôt d'avoir deux entités totalement différentes :
- l'entity MonApplication/FrontendBundle/Entity/MonEntity.php
- l'entity MonApplication/BackendBundle/Entity/MonEntity.php

Dans le front tu n'utilises que la première (il n'y a même pas de raison que le BackendBundle soit ne serait-ce que chargé), et inversement pour le back.

La surcharge aura certes pour avantage de mutualiser une partie du code, mais comme le code du front est à priori relativement léger, personnellement, ça ne me gène pas de le dupliquer dans mon entité back, d'autant plus que dans 80% des cas il s'agit des attributs, des accesseurs et de deux ou trois méthodes de (dé-)sérialisation.

De plus, je ne sais pas ce que tu entends par surcharge : s'il s'agit d'étendre la classe front pour en faire la classe back, je trouve que c'est une très grosse erreur de conception : d'un point de vue logique il n'y a pas de raison pour que l'un soit le parent de l'autre (et tu rajoutes un niveau de dépendance inutile).

Avec deux entités distinctes n'ayant pour point commun que la table sur laquelle elles sont mappées, il n'y a aucune gymnastique particulière à faire : juste implémenter les méthodes pour chacun des contextes dans lequel elles seront utilisées.

[pc.bertineau]

Mais à quoi ça te sert de ne pas voir les attributs "publics" dans ton Back ? L'idée c'est quand même d'avoir aussi accès à des données du Front dans le Back.

Exemple des comptes clients : Le nom et le prénom du client sont affichés dans le Front, mais tu ne peux pas t'en passer dans le Back...

Par contre dupliquer ta classe dans le Back et y ajouter des attributs supplémentaires, c'est assurément risqué ! D'où l'idée de surcharger. Tu ne vas tout de même pas maintenir 2 versions de ton fichier au lieu d'une quand tu voudras ajouter un attribut du Front à ton entité ?

[Nico_F]

Par contre dupliquer ta classe dans le Back et y ajouter des attributs supplémentaires, c'est assurément risqué ! D'où l'idée de surcharger. Tu ne vas tout de même pas maintenir 2 versions de ton fichier au lieu d'une quand tu voudras ajouter un attribut du Front à ton entité ?

Dans la mesure ou le contenu de ton entité front et de ton entité back n'est pas la même je ne considère pas ça comme maintenir deux versions d'une entité mais maintenir deux entités. L'utilisation de ton objet n'est pas la même dans le front et dans le back donc les entités doivent être différentes et ne pas dépendre l'une de l'autre même si tu as des attributs communs.

Maintenant je vois ce que tu veux dire : si tu modifies par exemple ton schema, les modifications de l'entité sont à faire dans le front ET dans le back. En soi je ne trouve pas que ce soit scandaleux dans la mesure ou ça n'a rien de trop contraignant (il est possible de générer les attributs et accesseurs depuis la console, même si l'objet existe déjà et sans l'écraser).

Je préfère 1000x ce cas de figure qui permet de garder une souplesse et une indépendance de chacune des entités plutôt que définir mon entité back comme étant la classe fille de mon entité front (qui est pour moi une erreur de logique et de conception : mon entité EntityBack n'est pas un type d'EntityFront : ce sont deux entités qui font des choses différentes sur une même table).

Je trouve moins dangereux de tomber sur des erreurs parce qu'une méthode n'a pas été implémentée ou qu'un attribut n'existe pas dans le back (auquel cas c'est assez rapidement relevé et corrigé), plutôt qu'oublier de surcharger une méthode dans la classe fille, et avoir des effets de bord silencieux parce qu'une fonctionnalité du front s'applique dans le back.

Pour finir, l'héritage d'une entité du front vers le back condamne l'héritage de cette entité dans le front dans des cas qui nécessiteraient vraiment de l'héritage. Tu ne pourras pas par exemple faire hériter certaines méthodes à une classe fille1(front) et empêcher que ces méthodes se retrouvent dans l'entité fille2(back). Ta méthode est soit protected, soit private mais pas les deux (tu pourrais aussi mettre toutes les méthodes en protected, tout surcharger dans la classe fille2(back) et les laisser vides pour qu'elles n'aient pas accès au traitement. Je classe ça dans la partie "gros goret").

[pc.bertineau]

Je trouve moins dangereux de tomber sur des erreurs parce qu'une méthode n'a pas été implémentée ou qu'un attribut n'existe pas dans le back (auquel cas c'est assez rapidement relevé et corrigé), plutôt qu'oublier de surcharger une méthode dans la classe fille, et avoir des effets de bord silencieux parce qu'une fonctionnalité du front s'applique dans le back.

On ne doit pas parler de la même chose. Pour moi, tout ce que tu peux faire sur une table en Front doit pouvoir être fait en Back. Mais pas le contraire justement...

[ozack]

Bonjour à tous,

Finalement je suis revenu au découpage premier que j'avais envisagé càd :
un backoffice et un front office... Mes entités ont glissé dans le back et j'ai copié les entités qui me serviront dans le front comme comme simple classe qui seront pilotées par un ensemble de manager...
Si conceptuellement la mise en place de "bundle" semble judicieuse, pratiquement ce me semble moins simple... le manque d'expérience peut être!
En tout cas merci de votre participation active et enrichissante !!!

[Nico_F]

Pour moi, tout ce que tu peux faire sur une table en Front doit pouvoir être fait en Back.

C'est avec ça que je ne suis pas d'accord. Il n'est pas toujours cohérent que le back puisse faire tout ce que fait le front. Soit parce que ce n'est pas prévu pour, soit parce que ça n'apporte aucune valeur ajoutée. Dans le cas d'un blog ou d'un site vitrine bateau, on a (plus ou moins) du read only coté front et du crud coté back. Donc en effet le back fait aussi du read.

Même pour un site e-commerce je serais presque d'accord avec ça car les actions de l'utilisateurs sont relativement limitées. Dès que tu as un front complexe ça change la donne : partons dans l'extrême opposé, tu développes un réseau social. Effectivement dans le back, tu peux créer des utilisateurs, avec leur nom prénom etc. mais il y a des choses que tu ne devrais pas pouvoir faire ou qu'il est inutile d'avoir dans le back.

En soi, est-il indispensable de pouvoir visualiser un itinéraire sur le backend de mappy ? Ca n'apporte rien : c'est pour le front cette fonctionnalité : dans le back cette visualisation ne sert à rien : tu édites des checkpoint, tu ajoutes des éléments à des coordonnées mais visualiser un itinéraire ça ne sert à rien dans le back.
Est-il indispensable de pouvoir suivre une personne ou un centre d'intérêt depuis le backend avec l'objet User ? Est-il indispensable de pouvoir faire tout ce que tu fais sur facebook ou twitter coté administration ? Je ne pense pas...
Dès fois il y a des coordonnées bancaires, des données sensibles, des éléments qui font que le front peut apporter des fonctionnalités que le back n'a pas que ce soit pour des raisons de sécurité, de confidentialité ou tout simplement parce que la fonctionnalité n'a pas sa place dans la partie administration.

Backoffice = administration de contenu
Frontoffice = actions relatives au contexte du site

[ozack]

Mon application est une application de e-commerce... et de fait, comme tu l'as souligné, les actions utilisateurs sur le front sont purement consultatives. Il n'y a dont rien en fait qui ne soit manipulé par l'utilisateur qui ne concerne directement le back.
Dans le cas qui m'occupe il me semble que cette organisation est conceptuellement plutôt pertinente.
Sinon je suis d'accord
Merci

[Seb33300]

Bonjour,

Je suis également à la recherche d'une solution pour une problématique relativement similaire sur un projet que je dois débuter prochainement.

En effet, je souhaiterais diviser mon projet en plusieurs bundle indépendant, notamment un pour le front office et un pour le backoffice.
Mais dans mon cas, d'autres "sites" en plus du front et back office seront amenés à se greffer au tronc principal.

Et je me suis retrouvé confronté à la même question que vous, comment organiser le code qui devra être partagé par les différents bundles ? Dont entre autre, les entités.

Je n'aime pas trop l'idée de Nico_F, à savoir recréer les mêmes entités dans chacun bundle avec uniquement les propriétés et méthodes utilisées par chaque bundle.
En effet, cela risque engendrer pas mal de duplication de code. Il n'est pas rare que sur un entité, une même propriété puisse être utilisé par tous les bundles. Ajouté au fait que si le modèle de données évolue, il faudra repasser sur tous les bundles pour mettre à jour X fois la même entité.

Après, je ne suis pas expert symfony 2, je débute dans ce framework et je viens donc vous demander votre avis sur la solution que j'ai imaginé :

Pensez vous qu'il soit possible de créer un bundle "noyau" qui contiendrait le code réutilisable par les autres bundle.

Aussi, j'ai lu dans la documentation de symfony qu'il est possible d'"étendre" un bundle. Peut être y a t il une solution de ce coté la ? Créer un bundle "noyau", et étendre tous les autre "bundle" de celui-ci ?
Mais je pense que l’héritage est plutôt utilisé pour modifier un bundle existant sans taper directement dans le code de celui-ci.

[Soobook]

Je me suis souvent interrogé face à ce genre de situation et vous lire ne fait que confirmer ce que j'en ai déduis : il n'y a pas de démarche clairement définie, il faut faire au cas par cas et au final on se retrouve souvent avec des bundles pas indépendant du tout.

Je suis vraiment fan de sf2, mais au sujet des bundles ils défèquent complètement dans l’adhésif. Cette organisation en bundles est une des pierres d'achoppement du framework, constamment mise en avant et plutôt bien pensée, mais quasiment pas documentée.

Pour moi, c'est avant tout une philosophie, et elle devrait être documentée, commentée, critiquée en profondeur par les auteurs, ce qui est très très loin d'être le cas.

Maintenant, une autre notion majeur du framework est celle de service.
Dans le cas où l'on doit accéder à une entité depuis plusieurs bundles, sans pour autant que les fonctionnalités qui lui sont liées ne varient d'un bundle à l'autre et ne justifient la solution de Nico_F, ne devrait-on pas partir dans cette optique?

En tout cas, perso et dans ce cas précis, j'aurais choisi la même solution que toi Ozack.

[pmithrandir]

quand je fais ma division, je réfléchi en terme de fonctionnalité et de coeur de métier.

Par exemple, j'ai 4 bundle dans mon site web :
- Admin
- Localisations
- User
- Site

-> Le site contient 99% de mes entités, c'est le coeur de mon projet.
-> Admin est juste un bundle interchangeable qui me permet de séparer mon code. J'ai utiliser Lyra bundle par exemple mais ca me permettrait de passer sur sonata très facilement. Ce Bundle utilise les entités de mon bundle coeur.
-> User et Localisations font l'inverse. Ils n'utilisent normalement aucune entité de mon cœur mais sont des dépendances pour celui ci. Ils lui ajoutent des fonctionnalités interchangeable avec d'autres projets.(je peux avoir besoin de mon user bundle ailleur, de même que celui qui me gère la localisation)

Pour l'instant, ca fonctionne plutot pas mal comme découpage.