J'ai la question exacte que ce type a: http: // Groupes. google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29
Je vais simplement copier-la coller ici:
Je me demandais quelles différentes façons d'organiser des paquets dans un Project Les personnes utilisent.
Je semble me retrouver avec un seul paquet massif pour un projet ou beaucoup des faisceaux qui sont étroitement liés (dépendants) les uns aux autres. par exemple;
J'ai implémenté ma propre entité utilisateur et mes formulaires de connexion, etc., mais les utilisateurs sont liés à une organisation (avec certaines fonctionnalités). Etc ... c'est principalement les entités qui se chevauchent beaucoup, je suppose ...
Est-ce que vous les séparez ou les déposons tous dans le même paquet?
3 Réponses :
Pour chaque projet, je commence avec une corebundle, où je mets tout ensemble. Ensuite, je viens de développer des fonctionnalités et, au fil du temps, je le réévalue - si je pourrais utiliser cette fonctionnalité quelque part ailleurs un jour (ou même libérer à la source ouverte), je le déplace vers un nouveau paquet.
"Taille" de la fonctionnalité d'une valeur d'une valeur séparée n'a pas vraiment d'importance - j'ai vu des paquets d'exploitation aussi gros qu'un fichier JS unique: D
Une chose à coup sûr - tout ce que tout dans un seul paquet est mauvais, il va à l'encontre de la raison pour laquelle cette architecture a été mise en œuvre en premier lieu!
Je commence aussi à utiliser CoreBundle, à moins que le projet ne soit pas grand, nous n'avons pas besoin de créer autant de faisceaux ... :) +1
Ma réponse dans le sujet suivant peut probablement vous aider: Symfony 2: Emplacement d'entités
Je ne suis pas une maîtrise symfony2, mais je pense avoir une bonne idée de la conception du paquet; Bien sûr, il n'y a pas de réponse universelle, mais vous pouvez suivre certaines «meilleures pratiques».
Tout d'abord, je ne pense pas que les gros faisceaux sont une bonne solution; Vous ne divisez plus votre projet en applications, comme vous l'avez fait avec Symfony1.4. Vous pouvez demander "mais que puis-je faire avec la logique frontale / backend?" ; assez facile, utilisez le contrôleur!
Chaque paquet doit se référer à un module, une pierre dans le mur de votre projet. Vous devez diviser votre application; De nombreux faisceaux ne sont pas mauvais. Bien sûr, ne faites pas un paquet pour chaque entité, ce serait une perte de temps. Mais imaginez une application de blog: vous auriez un ensemble d'utilisateurs, Bundle Articles (qui gérerait des postes, des catégories, ...), éventuellement un paquet pour les pages statiques, ...
Il n'est pas non lumineux que votre paquet soit lié; Vous construisez une application entière, donc dans ce cas, ils sont liés. Mais le mot clé ici est "généralisation"; Votre paquet doit pouvoir être lié à d'autres paquets, non seulement les vôtres. Vous devriez être en mesure de la réutiliser dans d'autres projets.
bonne chance!
edit : i < EM> NE PAS Utilisez des paquets pour un code spécifique à l'application, .
Personnellement, je préfère avoir un paquet par section d'une application. Par exemple:
C'est bon si l'application est une mishmash de plusieurs fonctionnalités, dont aucune n'est assez importante pour nécessiter une application distincte et / ou un sous-domaine. Mais si je développais une grande application de webstore, mes paquets seraient plus spécifiques:
Donc, je dirais que cela dépend du centre du projet. Ce qui est juste une section pour un projet pourrait être la fonctionnalité essentielle d'un autre.
et j'ai habituellement commonbundle , où tous les trucs communs vont, comme global CSS, images, mises en page, etc.
Il existe également au moins deux options pour l'organisation backend:
Personnellement, je vous penche vers la première option et vous pouvez en lire à ce sujet dans mon réponse précédente , mais il y a des gens qui Préfère avoir un paquet séparé pour le backend entier - en utilisant probablement l'un des Bundles admin . < / p>
Au fait, il est parfaitement acceptable pour les faisceaux d'être interconnectés - vous n'avez pas à les rendre tous indépendants de l'autre. Par exemple, JMSDIEXTRABUNDLE dépend de la Metadata Bibliothèque et JMSAOPBUNDLE , qui dépend à son tour Sur CG-Library . Si vous essayez de garder des paquets totalement indépendants, vous vous retrouverez avec de gros morceaux de code monolithique.
Merci beaucoup pour cette explication!
Cela semble que cela pourrait conduire à être une "question de discussion". En outre, de nombreuses réponses sont également valables ici sans un exemple concret du problème. Différentes combinaisons d'entités pourraient modifier la réponse par exemple:
utilisateur etorganisation (en supposant qu'il existe d'autres dépendances sur l'organisation dans le système) - des paquets différents.blogpostost etblogpostrevision - même paquet. C'est une intuition partiellement basée sur la conception du système - un paquet doit simplement encapsuler certaines fonctionnalités que vous considérez comme cohésives.