この男が持っている正確な質問があります: http://groups.google.com/group/symfony2/browse_thread/thread/cd35132cc6972f29
ここにコピーして貼り付けます。
人々が使用しているプロジェクト内でバンドルを整理するさまざまな方法を知りたいと思っていました。
プロジェクトの 1 つの大規模なバンドル、または互いに密接に関連する (依存する) 多数のバンドルのいずれかになってしまうようです。例えば;
私は独自のユーザーエンティティとログインフォームなどを実装しましたが、ユーザーは組織にリンクされています (いくつかの機能を備えています)。等々...多分重なっているエンティティがほとんどだと思います...
それらを分割するか、すべて同じバンドルにダンプしますか?
編集：アプリ固有のコードにバンドルを使用しなくなりました。
個人的には、アプリケーションのセクションごとにバンドルを作成することを好みます。例えば：
アプリがいくつかの機能の寄せ集めで、どれも個別のアプリケーションやサブドメインを必要とするほど大きくない場合、これは問題ありません。しかし、大規模な Web ストア アプリケーションを開発している場合、バンドルはより具体的になります。
つまり、それはプロジェクトの焦点によって異なります。あるプロジェクトの単なるセクションが、別のプロジェクトのコア機能になる可能性があります。
そして、私は通常CommonBundleを持っています。ここには、グローバル CSS、画像、レイアウトなど、すべての共通のものがあります。
また、バックエンド組織には少なくとも 2 つのオプションがあります。
個人的には最初のオプションに傾倒しており、以前の回答でそれについて読むことができますが、バックエンド全体に個別のバンドルを使用することを好む人がいます。おそらく管理バンドルの 1 つを使用します。
ところで、バンドルが相互接続されていてもまったく問題ありません。すべてを互いに独立させる必要はありません。たとえば、JMSDiExtraBundleはメタデータライブラリとJMSAopBundleに依存し、さらに JMSAopBundle はcg-libraryに依存します。バンドルを完全に独立させようとすると、巨大なモノリシックな 1 バンドルのコードの塊になってしまいます。
どのプロジェクトでも、すべてをまとめた 1 つの CoreBundle から始めます。次に、その中で機能を開発し、時間が経つにつれて再評価します。この機能をいつか別の場所で使用する可能性がある場合 (またはオープンソースにリリースする場合)、新しいバンドルに移動します。
個別のバンドルに値する機能の「サイズ」は実際には問題ではありません-1つのjsファイルと同じくらい大きいOSバンドルを見てきました:D
1 つ確かなことは、1 つのバンドルにすべてを詰め込むのはよくないということです。そもそもこのアーキテクチャが実装された理由全体に反することです。
次のトピックの私の答えはおそらくあなたを助けることができます: Symfony 2: エンティティの場所
私は Symfony2 の達人ではありませんが、バンドルの設計についてかなり良い考えを持っていると思います。もちろん、普遍的な答えはありませんが、いくつかの「ベスト プラクティス」に従うことができます。
まず第一に、大きなバンドルは良い解決策ではないと思います。Symfony1.4 で行ったように、プロジェクトをアプリケーションに分割する必要はもうありません。「でも、フロントエンド/バックエンド ロジックで何ができるの?」と尋ねるかもしれません。; 非常に簡単です。コントローラーを使用してください。
各バンドルは、プロジェクトの壁の石であるモジュールを参照する必要があります。アプリケーションを分割する必要があります。多くのバンドルは悪くありません。もちろん、エンティティごとにバンドルしないでください。時間の無駄になります。しかし、ブログ アプリケーションを想像してみてください。ユーザー バンドル、記事バンドル (投稿、カテゴリなどを管理するもの)、最終的には静的ページのバンドルなどがあります。
バンドルがリンクされていることは非論理的ではありません。アプリケーション全体を構築しているため、この場合はリンクされています。しかし、ここでのキーワードは「一般化」です。あなたのバンドルは、あなたのバンドルだけでなく、他のバンドルにもリンクできる必要があります。他のプロジェクトで再利用できるはずです。
幸運を ！