da.eXecutoR

Meine aktuelle Webapplikation soll Mandanten fähig sein unter berücksichtigung folgender Punkte:

1. Gemeinsames nutzen der Systemdateien. ( Wartungsfreundlichkeit )
2. Login via E-Mail Adresse ( Der gleiche Benutzer kann aber bei mehreren Mandanten registriert sein )
3. Eigene Datenbank für jeden Mandant. ( Backup/Restor Problematik )
4. Benutzerdateien für jeden Mandant seperat gespeichert in seinem Verzeichnis.

Ich habe mir das wie folgt überlegt:

Mandant A ist zum Beispiel Muster AG
Mandant B ist zum Beispiel Peter GmbH

Mandant A ruft die Seite via:

https://muster.meineapp.com

Mandant B ruft die Seite via:

https://peter.meineapp.com

auf.

Soweit so gut.

Die Struktur auf dem Server sieht wie folgt aus:

HST-meineapp/
HST-peter-meineapp/
HSt-meier-meineapp/

Im Ordner der jeweiligen Subdomain befindet sich eine PHP Datei wie folgt:

Hinter der dispatcher.php befinden sich div. Klassen & Dateien die dann für die eigentliche Anwendung geladen werden, sprich ich habe alle "System-PHP-Dateien" nur einmal.

Gibts einen Fix, dann braucht man nur 1x die entsprechende Datei zu erstetzen anstelle von 100x bei jedem Mandanten einzeln.

Die Datenbankstruktur ( vereinfacht dargestellt ) sieht wie folgt aus:

Master DB:

meineapp

Tabelle:

meineapp_customers
ID | Domain
1 | muster
2 | peter

Eine Funktion welche im dispatcher.php aufgerufen wird subtrahiert von der URL ( als. Beispiel https://muster.meineapp.com/de/proje...s-projekt.html ) die Subdomain.

Danach wird die gefilterte Subdomain "muster" in der Master Datenbank in der Tabelle meineapp_customers gesucht. Wenn vorhanden wird die ID zurückgegeben und in der Session der Datenbankname gespeichert.

meineapp_customer_db_1 ( Datenbank der Muster AG )
meineapp_customer_db_2 ( Datenbank der Peter GmbH )

Somit hat jeder Mandant seine eigene Datenbank sowie alle Dateien in seinem eigenen Verzeichnis auf dem Server

HST-meier-meineapp/uploads z.Bsp.

Durch diese Struktur haben wir auch die Möglichkeit einzelne Mandanten anzupassen wenn Sonderwünsche auftreten in dem wir z.Bsp. bevor wir die Datei:

HST-meineapp/include/printer/report.php

prüfen ob es eine

HSt-muster-meineapp/include/printer/report.php

gibt, und wenn ja soll diese eingebunden werden.

Somit können wir eine komplette Dynamik realisieren für jeden Mandant in dem wir einfach nur eine Subdomain setzen und eine Zentrale dispatcher.php einladen.

Nun würde ich gerne mal eure Meinungen zu diesem "Design" wissen damit ich meinen Ansatz verbessern kann.

Meine idee war ursprünglich lediglich wie ich es realisieren kann dass man beim Login nur Benutzer + Kennwort braucht, ohnen noch eine Kundennummer eingeben zu müssen.

Für mich sind damit folgende Punkte abgedeckt:

1. Patchen nur pro Server 1x notwendig.
2. Sicherung von Mandanten einzeln und unkompliziert möglich.
3. Restore Möglichkeit direkt ohne Software zu schreiben.
4. Mehrsprachigkeit kann zentral erweitert werden.
5. Benutzerdefinierte Dateien includen anstelle der DEFAULT System PHP-Datei
6. Login mit der gleichen E-Mail Adresse möglich bei verschiedenen Mandanten.

Hoffe es ist verständlich, ansonsten bitte ich um Nachbohren

Grüsse

eXe

Mister Ad

xm22

Und jetzt?

Chriz

Warum bekommen die Applikationen unterschiedliche Ordner? Mandantenfähigkeit heißt ja genau das zu vermeiden! Eine mandantenfähige Anwendung kann *durch Konfiguration* und nicht durch Kopieren oder Schaffung neuer Ordnerstrukturen mehrere Mandaten verwalten. Sprich dein Mandant parametrisiert die Anwendung, er ist nicht Platzhaltervariable für irgendwelche Ordnernamen. Zumindest würde ich das für eine unsaubere Implementierung/Interpretation einer mandantenfähigen Anwendung ansehen.

__________________
"Nuschel ich?" - "Was?"

da.eXecutoR

Nicht die Applikationen bekommen unterschiedliche Ordner, sondern jeder Kunde seinen eigenen. Somit sind die Dateien von einander getrennt und können ohne weiteres komplett gesichert werden ( zum Beispiel zum Kunden ) ohne dass ich dafür ein Skript schreiben muss.

Wie würdest du denn meine Ausgangssituation lösen?

1. Patchen nur pro Server 1x notwendig.
2. Sicherung von Mandanten einzeln und unkompliziert möglich.
3. Restore Möglichkeit direkt ohne Software zu schreiben.
4. Mehrsprachigkeit kann zentral erweitert werden.
5. Benutzerdefinierte Dateien includen anstelle der DEFAULT System PHP-Datei
6. Login mit der gleichen E-Mail Adresse möglich bei verschiedenen Mandanten.

Weitere Meinungen zu meinem Konzept?

Gruss

eXe

dr.e.

Welche Ansätze hast du denn bisher? Das Software-Design-Forum ist eigentlich dazu gedacht, vorhandene Ansätze zu diskutieren und keine Architektur-Beratung from the scratch durchzuführen...

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

da.eXecutoR

Danke für deine Antwort. Es ist richtig dass es sich zur Zeit noch um die Architektur handelt, aber läuft dies nicht ins Software-Design? Denn das ist ja schliesslich das Resultat dessen.

Wenn ich hier am falschen Ort gepostet habe bitte ich um Verschiebung.

Ich habe zur Zeit die beta Klasse für mod_rewrite ( Zuweisung und Abstraktion der Client Domains ).

Gruss

eXe

nikosch

Die Betonung liegt auf „from the scratch“. In diesem Forum solltest Du ansatzweise gängige Prinzipien für solche Anwendungsfälle kennen, um sie in Bezug auf Deine spezifische Anwendung diskutieren zu können.

„Wie macht man eigentlich“ gehört eigentlich in keines unserer Foren.

http://www.php.de/php-einsteiger/675...sumfragen.html

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

da.eXecutoR

Hallo nikosch

Ich habe ja bereits mein "Software-Design" / "Architektur" beschrieben. Mir gehts nur darum von jemandem der schon etwas Erfahrung hat zu wissen ob es komplett verkehrt ist aus Gründen die sich mir noch nicht offenbart haben oder ob ich mal "go ahead" gehen kann und loslegen.

Es ist keines Falls zu vergleichen mit einem Post

nikosch

Naja, Du redest aber hier von Datenbankstrukturen und Ordnernamen, die in der Konzeption überhaupt nichts verloren haben.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

da.eXecutoR

Wollte nur mein Konzept verständlich darstellen. Sollte nicht heissen, dass ich jetzt hier von jemandem erwarte wie ich das jetzt umsetzen muss.

Aber wenn keiner was dazu beitragen kann, schliesst ihr den Thread eben.

Grüsse & schönen Abend

eXe