Hintergrund: Wir haben App a, b und planen, weitere Anwendungen in die gleiche Anwendung hinzuzufügen. Die Apps sind so ähnlich, dass sie viele Ansichten, Assets und Aktionen teilen können. Derzeit leben a, b in einer einzigen App (2.3.10). c wird ähnlich genug sein, dass es auch in dieser Rails App sein könnte. Das Problem: Da wir fortfahren, mehr Apps zu dieser einen App hinzuzufügen, wird es zu viel Falllogik geben, dass die App bald zu einem Albtraum werden wird. Es wird auch potentielle Namespace-Probleme geben. Die Apps sind jedoch in Funktion und Layout sehr ähnlich. Es macht auch Sinn, sie in einer App zu speichern, so dass nur eine App gepflegt wird (da etwa 50% des Website-Looks/der Website-Funktionalität geteilt werden).Multi-Domain-Schienen-App. Wie kann MVC intelligent genutzt werden?
Wir versuchen, das so sauber wie möglich zu halten, damit mehrere Teams problemlos arbeiten und leicht gewartet werden können.
Einige Dinge, über die wir nachgedacht haben/versuchen: Engines. Machen Sie jede App zu einem Motor. Dies würde uns Routen auf der Domain basieren lassen. Es erlaubt uns auch, Controller, Modelle und Ansichten für die spezifische App herauszuziehen. Diese Lösung scheint nicht ideal, da wir die Apps in nächster Zeit nicht wiederverwenden werden. Und es scheint nicht richtig, den Host auf den Routen explizit anzugeben.
Skinning/Themen. Die Authentifizierungslogik wäre zwischen den Apps unterschiedlich. Jedes Benutzermodell wäre anders. Es ist also nicht nur ein Skinning-Problem.
Fügen Sie in app/view Ordner Sitea für Sitea Ansichten, SiteB für SiteB Ansichten und so weiter. Machen Sie das Gleiche für Controller und Modelle. Das ist immer noch ziemlich chaotisch und da es nicht den Namenskonventionen folgte, funktionierte es nicht so gut mit Rails und machte viel Code unordentlicher.
Eine weitere Rails App machen. Wir wollten einfach nicht denselben Controller oder View in 2 Apps behalten, wenn sie identisch sind.
Wir möchten, dass die App intelligent einen Controller verwendet, der auf dem Host basiert. Also würde es für jede App einen Sitzungscontroller geben und vielleicht einen übergeordneten Sitzungscontroller für die gemeinsame Logik (der jetzt nicht benötigt wird). In jedem dieser Sitzungscontroller wird die Authentifizierung für diese bestimmte App durchgeführt. Wenn die Domäne also an.mysite.com ist, würde sie den Sitzungs-Controller für die App verwenden und wissen, wie sie die Ansichten, Modelle und Controller der App nutzt. Und wenn die Domäne b.mysite ist, würde sie den Session-Controller für b verwenden. Und es gäbe ein Benutzermodell für ein und ein Benutzermodell für b, das ebenfalls von der Domäne bestimmt würde.
Hat jemand irgendwelche Vorschläge oder Erfahrungen mit dieser Situation? Und im Idealfall ist die Verwendung von Schienen 2.3.x als Aktualisierung auf Schienen 3 derzeit keine Option.
Wir werden diese Route versuchen. Danke für das Feedback von allen. – denial