Ich habe genau die Frage, die dieser Typ hat: Ссылка
Ich kopiere es einfach hier:
Ich habe mich gefragt, welche verschiedenen Arten der Bündelung in einem Projekt Leute benutzen.
Ich scheine mit einem riesigen Paket für ein Projekt oder viel zu enden von Bündeln, die eng miteinander verwandt sind. zB;
Ich habe meine eigene Benutzereinheit und Anmeldeformulare usw. implementiert, aber die Benutzer sind mit einer Organisation verknüpft (mit einigen Funktionen). Etc ... Es ist meistens die Entitäten, die sich überlappen, denke ich ...
Teilt ihr sie auf oder verteilt sie alle im selben Bündel?
Bearbeiten : I < em> nicht mehr mehr Pakete für App-spezifischen Code verwenden .
Persönlich bevorzuge ich ein Bündel pro Abschnitt einer Anwendung. Zum Beispiel:
Dies ist in Ordnung, wenn die App ein Mischmasch aus mehreren Funktionalitäten ist, von denen keine groß genug ist, um eine separate Anwendung und / oder eine Subdomain zu erfordern. Aber wenn ich eine große Webstore-Anwendung entwickeln würde, wären meine Bündel spezifischer:
Also, würde ich sagen, es hängt vom Fokus des Projekts ab. Was ist nur ein Abschnitt für ein Projekt könnte die Kernfunktionalität eines anderen sein.
Und ich habe normalerweise CommonBundle , wo all die üblichen Dinge wie globale CSS, Bilder, Layouts, etc. gehen.
Außerdem gibt es mindestens zwei Optionen für die Back-End-Organisation:
Persönlich lehne ich mich der ersten Option zu und Sie können darüber in meiner vorherigen Antwort nachlesen, aber es gibt Leute, die bevorzugen ein separates Bundle für das gesamte Backend - wahrscheinlich mit einem der Admin-Pakete .
Übrigens ist es völlig in Ordnung, dass Bündel miteinander verbunden sind - Sie müssen sie nicht alle unabhängig voneinander machen. Beispiel: JMSDiExtraBundle hängt von den Metadaten Bibliothek und JMSAopBundle , was wiederum von CG-Bibliothek . Wenn Sie versuchen, die Bündel völlig unabhängig zu halten, werden Sie große, monolithische Code-Bündel mit einem Bündel erhalten.
Für jedes Projekt beginne ich mit einem CoreBundle, wo ich alles zusammenstelle. Dann entwickle ich einfach Funktionen darin und im Laufe der Zeit werte ich es neu aus - wenn ich dieses Feature irgendwann einmal irgendwo (oder sogar als Open Source) verwenden möchte, verschiebe ich es in ein neues Bündel.
"Größe" der Funktion im Wert von separaten Bundle ist nicht wirklich wichtig - ich habe gesehen, OS-Bundles so groß wie eine einzige js-Datei: D
Eins ist sicher - alles in einem einzigen Paket zu stopfen ist schlecht, es widerspricht dem ganzen Grund, warum diese Architektur überhaupt implementiert wurde!
Meine Antwort im folgenden Thema kann Ihnen wahrscheinlich helfen: Symfony 2: Location von Entitäten
Ich bin kein Symfony2-Meister, aber ich denke, ich habe eine ziemlich gute Vorstellung vom Bündel-Design; Natürlich gibt es keine universelle Antwort, aber Sie können einige "Best Practices" befolgen.
Zunächst denke ich nicht, dass große Bündel eine gute Lösung sind; Sie teilen Ihr Projekt nicht mehr in Anwendungen auf, wie Sie es bei Symfony1.4 getan haben. Sie können fragen "aber was kann ich mit der Frontend / Backend-Logik tun?" ; Ganz einfach, benutze den Controller!
Jedes Bündel sollte sich auf ein Modul beziehen, einen Stein in der Wand Ihres Projekts. Sie müssen Ihre Bewerbung teilen; viele Bündel sind nicht schlecht. Natürlich, nicht ein Bündel für jede Entitäten, das wäre eine Verschwendung von Zeit. Aber stellen Sie sich eine Blog-Anwendung vor: Sie hätten ein Benutzer-Bundle, ein Artikel-Bundle (das Posts, Kategorien verwalten würde ...), eventuell ein Bundle für statische Seiten, ...
Es ist nicht unlogisch, dass Ihr Bundle verlinkt ist; Sie erstellen eine ganze Anwendung und sind in diesem Fall verknüpft. Aber das Schlüsselwort hier ist "Generalisierung"; Ihr Bündel sollte in der Lage sein, mit anderen Bündeln verbunden zu werden, nicht nur mit Ihren. Sie sollten es in anderen Projekten wiederverwenden können.
Viel Glück!