Mehrschichtige Anwendung

Guten Abend zusammen!

Ich entwickle derzeit eine Datenbank-Anwendung.

Das UI soll in C# und auch als ASP.NET entwicklet werden.
Ich habe deshalb beschlossen eine 3-Tier Architektur zu nutzen.

Ich habe nun folgende zwei Fragen:

a) sollten BL und DAL auf der gleichen physikalischen Maschine liegen? (Habe nen
Applikation-Server und nen DB-Server zur verfügung)

b) Wie kommuniziert das UI mit der BL bzw BL mit DAL? (Remoting?)

c) Welche Besonderheiten sind beim Berechtigungskonzept zu beachten??

Ich danke für Anregungen und Tips

Gruß
Tokka

Hallo Tokka,

Teilantwort:

zu a) ja, es sei denn es gibt so viel Last, dass eine Maschine damit überfordert wäre

zu b) da a) mit ja benantwortet wurde, ist kein Remoting nötig

herbivore

Hallo Tokka,

Ich schlage folgende physikalische Aufteilung vor:

Wenn nur wenige Clients gleichzeitig auf die Mittelschicht zugreifen:

Die Mittelschicht auf einem einzelnen Appserver oder sogar direkt auf dem Datenbankserver laufen lassen. Letzteres nur, wenn dort wirklich ausreichend Ressourcen vorhanden sind. So werden die Netzwerkzugriffe zwischen den Komponenten auf das Minimum reduziert.

Wenn nur viele (hunderte, tausende etc.) Clients gleichzeitig auf die Mittelschicht zugreifen:

Die Mittelschicht auf mehreren AppServer gleichzeitig laufen lassen. Damit kann die Last viel leicher bewältigt werden.

Zur Frage der Kommunikation zwischen den Schichten:

Wenn es absehbar ist, dass nicht hunderte oder tausende Benutzer gleichzeitig zugreifen, kannst Du .NET Remoting verwenden. Das ist leichtgewichtig und auch einfach zu implementieren.

Wenn Du die Anwendung so bauen möchtest, dass auch in einer Umgebung mit 1000 Benutzern keine Probleme hat, solltest Du Enterprise Services (COM+) verwenden (Ist im .NET Framework im Namespace System.EnterpriseServices). Dort hast Du die ganzen Tools, die man für solche großen Anwendungen barucht:*Just In Time Activation *Object Pooling *Verteilte Transaktionen *Queued Components (Unterstützung von Meldungswarteschlangen - MSMQ) *Komponenten können als Webservices veröffentlicht werden *Rollenbasierte Sicherheit (bei Geschäftsanwendungen sehr wichtig!)

Zur Frage des Bechechtigungskonzeptes:

Bei .NET Remoting wird auf Deinem Appserver ein Windows-Dienst laufen. Dieser Dienst verwaltet den Remoting-Host-Prozess. Alle Anfragen von Clients gehen an diesen Dienst. Der Dienst läuft unter einem eigenen Benutzerkonto. Deshalb hat Deine Mittelschicht alle Berechtung dieses Dienstkontos. Das ist eine gute Möglichkeit, den Datenbankzugriff abzusichern. Gib einfach nur diesem Konto Zugriff auf die Datenbank. Die Clients dürfen mit ihren Benutzerknoten nicht direkt auf die Datenbank zugreifen. Wenn sie Daten wollen, müssen sie auf die Mittelschicht zugreifen. Remoting verfügt leider nicht über eine weitergehende Authentifizierungsunterstützung, da es für einfache Remote Procedure Calls gedacht ist. Sowas muss bei Verwendung von .NET Remoting von Hand gebaut werden. Du musst z.B. sicherstellen, dass z.B. nicht jeder Benutzer alle Funktionen der Mitterschicht aufrufen kann. Stell Dir vor Du hättest eine Komponente "LohnInfo". Es wäre für einen in C# versierten Mitarbeiter kein Problem mit Notepad einen kleinen Client zu bauen, der die Löhne und Gehälter aller Kollegen abruft. Sich darauf zu verlassen, dass die Anwender nicht wissen wie sowas geht oder auf welchem Server was ist, kann gefährlich sein. Überhapt bei größeren Firmen stellen unzufriedene interne Mitarbeiter ein großes Problem dar.

Ein sicheres und durchdachtes Berechtigungskonzept gibt es bereits fertig anwendbar. Und zwar bei Enterprise services (COM+). Dort lassen sich Rollen definieren. Die können als Attribute im C#-Code oder mit dem COM+-Katalog auf dem Appserver konfiguriert werden. Den Rollen werden Windows-Benutzer bzw. Windows-Sicherheitsgruppen zugeordnet. Rollen lassen sich im Programmcode einfach abfragen. Auf diese Weise wissen Deine Komponenten immer, welche Rollen der aktuell zugreifende Clientbenutzer hat. Man kann auf Methodenebene C#-Attribute deklarieren, die festlegen, welche Rollen die Methode ausführen dürfen und welche nicht. Da dieses Sicherheitssystem direkt ins Windows-Betriebssystem integriert ist, kann es nicht einfach umgangen werden.

Mahlzeit die Herrschaften 🙂

Original von herbivore
Hallo Tokka,

Teilantwort:

zu a) ja, es sei denn es gibt so viel Last, dass eine Maschine damit überfordert wäre

zu b) da a) mit ja benantwortet wurde, ist kein Remoting nötig

herbivore

Nun ja, wie greife ich dann vom Client auf die BL zu? Gebe ich beim Methodenaufruf den UNC Pfad zum Server mit??

@Rainbird: Danke für die sehr genaue Erklärung! Werde mir auch mal die EnterpriseServices ansehen

Gruß
Tokka

Hallo Tokka,

warum läuft der BL nicht zusammen mit den UI auf dem Client-Rechner? 3-Tier Architektur heißt ja nur, dass man verteilen kann, nicht dass man muss. In vielen Fällen reicht UI+BL+DAL auf dem Client-Rechner und DL (will heißen DB) auf dem DB-Server.

herbivore

@herbivore: Natürlich. Für eine Anwendung mit 5 gleichzeitigen Usern ist das völlig in Ordnung. Es ist sogar performanter. Man hat nur einen Netzerkzugriff (den zum DB-Server) anstatt zwei (zum Appserver und vom Appserver zum DB-Server). Man neigt aber dazu alles in einem Prozess auszuführen und alles ziemlich eng miteinander zu verdrahten. Dann hat man Probleme die Anwendung zu verteilbar zu machen, wenn die Nutzerzahl wächst. Am besten zwei Prozesse bauen. Ein GUI-Prozess und ein BL-Prozess. Ob die beiden auf dem gleichen Rechner laufen oder auf unterschiedlichen ist dann mehr ein Admin Problem. Es funktioniert das eine wie das andere.

@Tokka: Schau Dir einfach die folgenden zwei Schulungsvideos an, dann hast Du den Überblick:

.NET Remoting: http://www.microsoft.com/germany/msdn/nettv/folge1.mspx

Enterprise Services: http://www.microsoft.com/germany/msdn/nettv/folge3.mspx

Vielen Dank an Rainbird und herbivore!

Ich werder mir mal die beiden Videos angucken und mir nochmal Gedanken machen!

Schönes wochenende.

Gruß
Tokka