Problem:
Ich bin unsicher, wie Sie eine Multi-Client-Anwendung für Symfony einrichten, damit wir nicht gegen Symfonys Best Practices verstoßen und gegen das Framework arbeiten.
Ich hätte gerne einen Haupt-Core-Namespace, der alle Basismodellklassen enthalten würde. Direkt neben dem Core möchte ich clientspezifische Namespaces einrichten, die basierend auf den regionalen Clienteinstellungen verwendet werden. Zum Beispiel LocalUS für den US-Markt, LocalUK, für den UK-Markt usw.
Die lokalen * Namespaces sollten die erste Priorität für das Einbinden von Zweigvorlagen haben und als Fallback gemeinsame gemeinsame Ansichten verwenden (wie ich es verstehe, ist dies über Zweig-Namespaces lösbar) . Gleiches gilt für Controller und Modelle - diese sind wahrscheinlich über die Erweiterung der Core-Namespace-Klassen lösbar? Ist das alles über Routing und Pfade für diese Local * -Controller lösbar?
Ich schaute auf GitHub auf, um zu sehen, ob es irgendwelche Projekte gibt, die ähnliche Einstellungen haben, aber ich konnte nichts finden.Symfony: Organisation der Geschäftslogik von Multi-Client-Anwendungen
Ein wenig Hintergrund:
Wir haben eine ältere Legacy-PHP-Anwendung, die in-house von Grund auf mit einfachen PHP gebaut wurde. Da die Anwendung im Laufe der Zeit gewachsen ist, ist es schwierig geworden, eine gute Codequalität und -standards aufrechtzuerhalten. Es ist auch sehr zeitaufwendig, neuen Entwicklern unsere Anwendungslogik beizubringen, da die Anwendung im Grunde keinen Standarddesignmustern folgt und nur ihre eigene Sache macht. Ein großer Teil des zugrunde liegenden Codes, der Routen, Controller usw. behandelt, scheint wie "Magie" zu funktionieren, die niemand wirklich zu berühren wagt.
Aus diesem Grund möchten wir unsere Anwendung auf das Symfony3 Framework migrieren. Ich habe einige Artikel über den gesamten Prozess der Migration von Legacy-Anwendungen auf Symfony gelesen und es geschafft, es mit Silex ziemlich gut zu machen. Silex, ist jedoch ein bisschen zu leicht, fand ich, dass der Assestic Service Provider eine Menge Funktionen fehlte (Zweig Namespacing etc) und entschieden, dass es am besten wäre, wenn wir stattdessen zu einem vollständigen Stack Symfony Framework bewegen könnten.