Salut,
Je souhaiterais savoir comment vous démarrez un projet.
J'ai l'impression que beaucoup d'entre vous créent un Bundle pour le projet (style Moi\MonProjetBundle ) ? Pouvez vous m'expliquer pourquoi un tel choix ?
Salut,
Je souhaiterais savoir comment vous démarrez un projet.
J'ai l'impression que beaucoup d'entre vous créent un Bundle pour le projet (style Moi\MonProjetBundle ) ? Pouvez vous m'expliquer pourquoi un tel choix ?
Perso j'ai mon bundle métier MainBundle, qui contiens mes entités métiers
J'ai souvent un userBundle quand ma gestion des utilisateurs est secondaire.
J'ai un ImportBundle qui contient mes scripts d'import Excel du client vers la base par exemple, avec seulement les entités qui correspondent à cette gestion: par exemple les paramètres d'import ou l'historique des imports réussis/échoués etc...
Ducoup, on travaille principalement dans le mainBundle, sans être parasité par les entités et par les fonctions secondaires de l'application.
On a pas pour objectif de faire des bundles pour les poser sur github
Entre nous ces bundles pourraient être privé et hébergé sur vos serveurs avec un petit satis pour faire bien.
J'imagine que tu places les assets propre au projet dans ce MainBundle ? Tu ne travailles jamais dans le dossier app ?
Dans app j'ai juste mes 2 layouts (un layout pour l'utilisateur connecté, un layout pour les erreurs 500, la page de login etc.. donc pour un utilisateur a priori non connecté), et mes pages d'erreurs
Après ce dossier n'est qu'un concentré de configurations (config, cache) et de diagnostique (logs) de l'appli, je me vois pas travailler dedans
Hello,
Je vais apporter le témoignage inverse : je n'ai pas de bundle qui regroupe tout le projet et dans la mesure du possible, j'essaye autant que faire se peut de ne pas avoir non plus un mainBundle dans lequel se trouve "le cœur du projet" et encore moins mes classes métier.
J'essaye de faire en sorte que chacune des parties de mon projet soit la plus indépendante possible et donc je démarre avec le premier bundle dont j'ai besoin. Si mon projet contient un blog, je peux commencer par un BlogBundle : les entités métier (articles, tags, commentaires etc.) se trouve dans ce BlogBundle, ensuite je rajoute un espace avec des jeux : je fais un GameBundle, ensuite un autre espace avec un eshop, je fais un EshopBundle etc.
Comme gototog je n'ai pas l'intention de publier publiquement mon code sur github pour en faire des bundle publics, par contre j'aimerais bien pouvoir voir les dépendances de chacun de mes bundles, et le jour ou j'aurai besoin de réutiliser une partie dans un autre projet, j'aimerais qu'il y ait le moins de travail possible. C'est pour cette raison aussi que je ne fais pas de BackofficeBundle par exemple. Chaque bundle possédant des entités ayant besoin d'être managées dans un backoffice contient également la partie backoffice dans ce même bundle. De cette manière je peux (si le couplage avec le reste du projet n'est pas trop fort) réutiliser ce bundle dans un autre projet. et avoir le front et le back de prêts.
Autrement pour réutiliser mon bundle eshop, je dois récupérer mes entités métiers qui selon la méthode de gototog se trouvent dans le mainBundle, mon Backoffice qui selon certains se trouvent dans un BackofficeBundle et le reste du code qui logiquement doit se trouver dans un EshopBundle.
Sinon pour les assets, l'idéal est de les regrouper également par bundle, pour les mêmes raisons que le backoffice, le métier ou autre chose.
Par contre je ne vois pas bien ce que tu veux dire par "Tu ne travailles jamais dans le dossier app ?". Ce dossier contient la configuration de ton projet et de chacun de tes bundles, donc fatalement tu dois mettre les mains dedans mais il n'y a rien en rapport avec la partie métier.
Ah oui, c'est vrai que le contexte est important.
Je travaille sur des applis utilisées en interne par des entreprises, qui n'ont pas grand chose a voir avec du dev web général.
On a jamais de gestion d'article, de news, de parties e-commerces etc.
Le découpement de Nico est tout à fait pertinent (mais ne correspond pas à mon utilisation).
Partager