Ankündigung

Einklappen
Keine Ankündigung bisher.

Symfony2 Mandantenfähigkeit

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Symfony2 Mandantenfähigkeit

    Hallo zusammen,

    ich suche nach einer eleganten Möglichkeit in Symfony Code mandantenfähig zu gestalten.

    Ein Beispiel: Die Mandanten A bis Z verwenden die gleiche Funktionalität um eine Terminanfrage zu senden. Mandant F möchte jetzt aber noch ein weiteres Feld "Techniker erforderlich" und darauf eine weitere Funktion "Auswahl Techniker" dazwischen schalten.

    Um weiterhin allen Mandanten Updates anbieten zu können soll diese Erweiterung im vorhandenen Code intergriert werden. Hierbei wäre es wünschenswert den Mandant-F-Code auch deutlich als solchen zu erkennen.

    In diesem Fallbeispiel müssen Model, View und Controller erweitert werden bzw. im Controller eine vorhandene Methode überschrieben werden.

    Ich habe bereits eine Lösung gebaut in dem ich die Loader-Klassen von Symfony mit einem Environment-Abhängigen Eigenbau ersetzt habe, aber das setzt leider vorraus das ich mehrere Klassen mit gleichem Namespace und gleichem Namen habe um sie austauschen zu können.

    Die Lösung funktioniert prinzipiell nur bin ich damit mehr als unglücklich, da auto-completion und Übersichtlichkeit darunter leiden.

    Wisst ihr elegantere Lösungen?

    Gruß
    cx


  • #2
    Im besten Falle machst du die FormTypes dynamisch und bekommst die Informationen, welche Formularfelder erstellet werden müssen aus der DB.

    Am Code "basteln", weil ein Mandant spezielle Anforderungen hat halte ich für gewagt. Das macht das Ganze Konstrukt unwartbar.
    GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

    Kommentar


    • #3
      Spontan kommen mir verschiedene Sachen in den Sinn:

      - Controller as a Service (Somit austauschbar)
      - Eigene Bundles pro Kunde welche als parent ein BaseBundle haben
      - Alles nur über GIT trennen (Pro Kunde ein Branch)

      Code in die Datenbank verlagern finde ich keine gute Lösung. Vorallem die Formkomponente ist ultra komplex mit den Listeners und den Guessern usw. das will man sich nicht noch auf der DB antun.

      Wirklich gemacht habe ich es aber bisher noch nie.

      Kommentar


      • #4
        @ChrsitianK; Du meinst EAV? Oder ein großes gemeinsames Model und die Templates in die Datenbank verlagern? Das bringt aber andere Probleme mit sich, mal abgesehen davon ist im genannten Beispiel eine Art Wizard, das heisst bei Mandant F kommt der Schritt der Technikerauswahl nach absenden des Formulars, bei den anderen nicht. Dann müsste ich also auch das Routing und ggf. andere Sachen in die Datenbank verlagern. Das klingt nach Eierlegendewollmilchsau.

        Kommentar


        • #5
          @mYkon: Controller as a Service löst aber nur einen Teil der Problematik. Funktioniert das mit dem BaseBundle auch mit allen Komponenten? Also kann ich auch includete Templates überschreiben, Models um einzele Felder erweitern etc. ? Das mit den git ist sicherlich eine Lösung, aber schön ist was anderes

          Kommentar


          • #6
            Zitat von cycap Beitrag anzeigen
            @ChrsitianK; Du meinst EAV? Oder ein großes gemeinsames Model und die Templates in die Datenbank verlagern? Das bringt aber andere Probleme mit sich, mal abgesehen davon ist im genannten Beispiel eine Art Wizard, das heisst bei Mandant F kommt der Schritt der Technikerauswahl nach absenden des Formulars, bei den anderen nicht. Dann müsste ich also auch das Routing und ggf. andere Sachen in die Datenbank verlagern. Das klingt nach Eierlegendewollmilchsau.
            Ok, das habe ich so etwas überlesen. Ich hätte so oder so kein "Code" in die DB gelegt (würde ich nie machen!), sondern nur die Meta-Information wie das Formular aussieht. Also etwas ähnliches, was jedes ERP macht... Steigert vermutlich die Komplexität in deinem Falle zu enorm.

            Dann bin ich eher für Vorschlag 2 von mYkon: Ein BaseBundle worauf die Kunden erweitern und du kundenspezifische Dinge implementieren kannst.
            GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

            Kommentar


            • #7
              Wie unterscheidest du denn eigentlich die Mandanten? Sind das losgelöste Applikationen oder bekommst du erst zur Laufzeit mit, dass da der User XY zum Mandant Z gehört?

              Kommentar


              • #8
                Wie oben beschrieben ist das Abhängig vom Environment. Ich setze also je nach vhost / subdomain ein anderen Environment. Die Mandanten haben auch getrennte Datenbanken.

                Kommentar


                • #9
                  Bietet Symfony nicht auch einen EventDispatcher an?

                  Du könntest somit ein Event schreiben und an den benötigten Stellen feuern, wenn Mandant F damit arbeitet. In dem Event Objekt könntest du ja Controller, Model und View erweitern. Ich kann dir aber auch nicht sagen wie weit das bei Symfony ausgeprägt ist.
                  Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                  http://www.lit-web.de

                  Kommentar


                  • #10
                    Hallöchen,

                    im Prinzip würde es ja ausreichen die entsprechenden Klassen zu erweitern und in der Datenbank die Namen der zu verwendenden Klasse abzulegen. Je nach Anforderungen muss man das eventuell ein wenig komplexer aufziehen. Ich stelle mir das im Grund so vor:

                    Pseudo-Code:
                    PHP-Code:
                    // Simples Interface für den Form-Controller
                    interface FormBehavior{ .. }

                    // Standard-Implementierung
                    class DefaultController implements FormBehavior {..}

                    // Kundenspezifische Implementierung
                    class SpecialController extends DefaultController {..} 
                    Konfiguration / Datenbank:
                    PHP-Code:
                     ID ClientID Module Controller
                    --------------------------------------------
                     
                    1  50       login  DefaultController
                     2  
                    71       login  SpecialController 
                    Ich habe noch mit im Detail über diese Idee nachgedacht, aber wäre das eventuell eine mögliche Richtung?

                    Viele Grüße,
                    lotti

                    Kommentar


                    • #11
                      Das entspricht in etwa dem was ich jetzt habe, nur das ich halt in den Pfaden schaue ob Special-Klassen existieren oder nicht und das nicht über die Datenbank steuere. Hat der SpecialController einen eigenen Namen, dann ändern sich alle routen, deshalb gibt es bei mir einen BaseController mit den eigentlichen Standard-Methoden, einen Default-Controller der nichts weiter tut als vom Base zu erben und x SpecialController die genau so heissen wie der DefaultController (und im gleichen NS liegen) um den Default-Controller mit dem Special-Controller nahtlos zu ersetzen.

                      Kommentar


                      • #12
                        Hallo,

                        weil es gerade (glaube ich) zum Kontext passt und ich es mich selbst schonmal gefragt habe poste ich es mal hier dazu: Ist es Software-Design-Technisch "gut" den Request über eine Route auf einen Controller zu leiten welcher dann anhand von gewissen Parametern (diese sind ja im Grunde unwichtig) welcher Subcontroller und welche Methode dessen tatsächlich auszuführen sind? Würde man einen solchen Controller dann "Dispatcher" nennen?
                        Gruß,
                        SebTM

                        Kommentar


                        • #13
                          Na Shopware 4 setzt ja auf Symfony Komponenten und Zend. Die machen das mit den Klassen so wie du das beschrieben hast, allerdings in Form von Event und Hook Listenern. Ich finde die haben das ganz clever gelöst.
                          Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                          http://www.lit-web.de

                          Kommentar


                          • #14
                            Zitat von SebTM Beitrag anzeigen
                            Hallo,

                            weil es gerade (glaube ich) zum Kontext passt und ich es mich selbst schonmal gefragt habe poste ich es mal hier dazu: Ist es Software-Design-Technisch "gut" den Request über eine Route auf einen Controller zu leiten welcher dann anhand von gewissen Parametern (diese sind ja im Grunde unwichtig) welcher Subcontroller und welche Methode dessen tatsächlich auszuführen sind? Würde man einen solchen Controller dann "Dispatcher" nennen?
                            Moin,

                            dass verstehe ich grad nicht ganz! Subcontroller? Was meinst du damit? Willst du hiermit gerade eon in die Richtung HMVC?

                            Letztenendes braucht es Informationen aus dem Request für ein Routing.
                            Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
                            http://www.lit-web.de

                            Kommentar


                            • #15
                              Hallo,

                              im Grunde würde es wohl auf das von dir beschriebene "HMVC" (http://techportal.inviqa.com/wp-cont...2/MVC-HMVC.png) rauslaufen. Allerdings eben nur in einer Ebene - ein Standard-Controller der eben anhand der Daten aus der Datenbank z.B. den korrekten Controller mit Methode aufruft.

                              Falls das doch was längeres werden sollte würde ich es auch in einen eigene Thread auslagern
                              Gruß,
                              SebTM

                              Kommentar

                              Lädt...
                              X