ASP.NET Membership Architektur Frage

Hallo,

ich hätte eine Frage bezüglich der Architektur eines bestimmten Projektes. Es ist eine grundlegende Frage für den Entwicklungsentwurf, ich will nicht das Ihr meine Hausaufgaben macht.. (ja ich habe die Regeln gelesen ;D)

Es geht also um folgendes :

Und zwar soll ich eine Website entwickeln, die von mehreren Kunden (bzw. deren Mitarbeitern) konsumiert werden kann.

Meine Website stellt ein Backend-Interface bereit, mit dessen Hilfe für jeden Kunden eine eigene Datenbank für die entsprechende Datenhaltung bereitgestellt werden kann.

Beispiel :

Kunde 1 (Firma 1) --> DB 1 (enthält Tabellen : tblMitarbeiter, tblAufgaben, usw..)
Kunde 2 (Firma 2) --> DB 2 (enthält Tabellen : tblMitarbeiter, tblAufgaben, usw..)
Kunde 3 (Firma 3) --> DB 3 (enthält Tabellen : tblMitarbeiter, tblAufgaben, usw..)
and so on..

Ich möchte diese Art der Datenhaltung, da Sie sehr gut skalierbar ist und ich die größste Kontrolle & Komfort über die Rechteverwaltung habe.

Jetzt zu meinem Problem :

Mitarbeiter Max Mustermann von der Firma 1 möchte Sie an der Website anmelden.

Das Standard ASP.NET Login Control greift ja standardmäßig auf die aspnetdb.mdf im App_Data Ordner zu (bzw. auf die Datenbank die man bei Ausführen des Assistenten für das Benutzer-Rollen Managment angegeben hat (ist ja jetzt mal egal wo die liegt) und der Benutzer der Website wird anhand seiner eingegebenen Benutzername, Passwort-Kombination gegen die Datenquelle authentifiziert.

Das heisst allerdings das ich nicht die tblMitarbeiter Tabelle der Firma 1 in der DB1 für die Authentifizierung nutzen kann, da ich ja nicht weiss in welcher Firma der Mitarbeiter der sich an der Website anmelden will arbeitet..

Ich würde jetzt hingehen,das Login Control in eine Vorlage konvertieren und ein weiteres Feld "Firma" hinzufügen. Dadurch wüsste ich in welcher Firma der Kerl arbeitet der sich anmelden will, und kann mir den ConnectionString für die richtige DB holen (DB's können auf verschiedenen SQL Servern liegen).

Oder ich könnte hingehen und bei einer "Kundenerstellung" (also Kunden DB Erstellung) eine extra WebsiteAdresse vergebem..

z.B.

website.de/kunde1
website.de/kunde2
usw.

oder würde sogar unter Verwendung der Membership API mir einen eigenen MemberShip Provider schreiben (müssen?)

So ich entschuldige mich wenn's die Beschreibung zu umfangreich war, und ihr dachtet : "wann kommt der mal zum Ende.."

ich habe erfahrung mit c#, bin aber absoluter Neuling was ASP.NET angeht..

Kann mir einer von euch sagen, ob man oben genanntes szenario generell so angeht oder ich komplett falsch liege?

lg menti

es gibt noch einen weiteren Grund für die Angabe der Firma bzw. eigene Subdomains: was, wenn "Hans Müller" in Firma 1 und in Firma 2 existiert?

Das einfachste im Sinne der Architektur ist wohl eine Anwendung pro Kunde. Ansonsten würde ich weniger auf mehrere Datenbanken sondern eher auf mandantenfähigkeit hin entwickeln.

hey GarlandGreene,

erstmal danke für die schnelle antwort.

guter gedanke das mit dem kunden in zwei firmen, aber den schliess ich erstmal aus. Wenn der Kunden nachher will, kann das nachträglich berücksichtigend einprogrammiert werden.

eine anwendung pro kunde? damit meinst du 1 website pro kunde?

kann ich so nicht machen.. das Backend Interface bekommt nachher ein Hauptkunde.
Der verkauft das Produkt (also die Konsumierung der Website auf Frontend-Seite) dann an n-Kunden.

Heisst außerdem :

Wenn ich zum Beispiel erst nachprogrammiere für die Website und es gibt bereits laut deinem Vorschlag 10 Websiteanwendungen (da 10 angelegte Kunden) müsste ich die Änderungen an 10 verschiedenen Stellen machen. Selbst wenn ich dll's nutze.

was meinst du mit mandantenfähigkeit ?

lg menti