Ist eine 3 (physische) Tier-Architektur ineffizient?

Question

Hinweis: Wenn ich mich auf eine Ebene beziehe, meine ich eine physische Ebene. Viele der Fragen auf dieser Seite, die sich auf "Tiers" beziehen, beziehen sich auf logische Ebenen, was ich nicht möchte.

Ich entwerfe eine App mit einer Standard-3-Layer-Architektur, mit Präsentations-, Business-Logik (BLL) und Datenzugriff (DAL) Schichten. Die Technologie ist WPF, C#, LINQ und SQL Server 2008. Meine Frage bezieht sich auf die physische Architektur dieser App.

Ich kann die BLL/DAL in einer Standard-DLL platzieren, die auf dem Benutzercomputer geladen und ausgeführt wird, wodurch eine 2-Tier-Architektur - Client-Maschine und Datenbankserver - entsteht. Aber es ist nicht allzu schwierig, den BLL/DAL in einen WCF-Dienst umzuwandeln, der auf einem App-Server sitzt und von der Benutzermaschine aus aufgerufen wird. Dies würde mir eine 3-Tier-Architektur geben - Client-Maschine, App-Server und Datenbank-Server.

Meine Frage ist das - was ist der Vorteil der Verwendung einer 3-Tier-Architektur? Mir wurde oft gesagt, dass 3 Ebenen Skalierbarkeit hinzufügen, aber es ist mir nicht sofort klar, warum das so sein würde. Und sicherlich werden Sie einen Performance-Hit mit den gleichen Daten machen, die zwei Hops über den Draht machen müssen - vom Datenbankserver zum App-Server, dann vom App-Server zum Client-Rechner.

Ich würde den Rat von erfahrenen Architekten und Entwicklern da draußen schätzen.

Answer 1

Es hängt von der Verwendung Ihrer Anwendung und Ihrer Sicherheitsanforderung ab. Wenn Ihre Anwendung über das Internet verwendet wird und Sie potenziell potenziell sensible Daten speichern, wird dringend empfohlen, die physische Entfernung für die Datenbank hinzuzufügen. Lassen Sie niemals jemanden von außen auf eine Maschine mit direktem Zugriff auf Ihre Datenbank. Menschen können und werden versuchen, Ihre Sicherheit aus keinem besseren Grund zu brechen, als sie nichts Besseres zu tun haben.

Skalierbarkeit kann sowohl vor der Präsentationsebene (vor den Webservern) als auch in der Datenbank ein Faktor sein. Durch das Platzieren eines Lastenausgleichsmoduls vor der Präsentationsschicht können eingehende Anforderungen an ein Array von Maschinen weitergeleitet werden, die unabhängig voneinander verwaltet werden können. Maschinen können in Zeiten des Bedarfs zum Pool hinzugefügt und zur Wartung entfernt werden. Das Platzieren von Lastenausgleichern zwischen den anderen Ebenen kann die gleiche Auswirkung haben. Die Idee ist eine flexible, dynamische Backend-Umgebung, die je nach Bedarf angepasst werden kann.

Answer 2

Es kann sein. Es hängt davon ab, was umgesetzt wurde und wie.

Die treibende Kraft beim Erstellen einer 3-stufigen physischen Architektur ist nicht unbedingt leistungsbezogen.

Der Grund, warum Skalierbarkeit angegeben wird, ist, dass ein Dienst möglicherweise auf einer Serverfarm ausgeführt wird, die Clients dies jedoch nicht bemerken. Die Größe der Serverfarm kann erhöht werden, um den Bedarf zu decken, wenn die Architektur dafür ausgelegt wurde.

Answer 3

Ineffizienz ist im Auge des Betrachters.

Wenn beispielsweise alles auf dem Client passiert, kann der Speicherbedarf oder die CPU/Netzwerkanforderungen der Clientcomputer steigen. Wenn diese Arbeit auf eine Server/Server-Farm ausgelagert werden kann, müssen Sie möglicherweise Hardware-Upgrades von Client-PCs durchführen, nur um Ihre Software auszuführen. Wenn mehr Ressourcen oder Upgrades benötigt werden, können sie in der Business-Logik-Ebene hinzugefügt oder ausgeführt werden, ohne die Clients zu beeinträchtigen.

Auch wenn die Geschäftslogik auf ihrer eigenen Ebene möglicherweise später (aus Sicht der Softwareentwicklung) effizienter ist, wenn Sie einige Funktionen Ihrer Anwendung in einem webbasierten System oder einem Outlook-Add-In bereitstellen müssen, oder eine iPhone App.Sie möchten nicht alle diese Systeme aktualisieren müssen, wenn sich die Geschäftslogik geringfügig ändert.

Die Sicherheit ist möglicherweise besser, da Ihre Benutzer keinen direkten Zugriff auf den Datenbankserver benötigen, da sie vom Anwendungsserver isoliert werden.

Es zwingt Sie auch, über Ihre Anwendung in einer modularen Weise mit gut definierten Schnittstellen nachzudenken, die architektonische Vorteile für das Design Ihrer Anwendung haben können.

Answer 4

Wann immer Sie die Frage stellen "Ist X ineffizient?" Sie sollten sofort, fragen Sie sich drei Vorläufer Fragen:

1. Mit „ineffizient“, welche Ressource denken Sie, es effizient sein sollte mit und möglicherweise nicht? Zeit? Raum? Bandbreite? Entwicklungsstunden?

2. Warum kümmert es dich? Nein, im Ernst: Wenn Sie nur eine Minute brauchen, um diese Frage zu beantworten, muss es einen Grund geben. Was ist der Grund?

3. Im Vergleich zu was?

Soweit Ihre Kommentare über Skalierbarkeit angeht: Eine Zeit lang hatte ich die unglückliche Verantwortung ein System, dessen Architekt aufrechtzuerhalten, der gesagt hatte, dass in der Datenbank Rundfahrten zu minimieren würde eine Anwendung skalierbar machen. Er nahm diese Einsicht und lief damit. Sie können über dieses Projekt lesen here. Mir fällt ein, dass ich hätte erwähnen sollen, dass zu keinem Zeitpunkt während der gesamten Lebensdauer von über zehn Jahren mehr als vier Benutzer gleichzeitig angemeldet waren.

Answer 5

Der Hauptvorteil der beschriebenen 3t-Anwendungen ist nicht die Skalierbarkeit. Wartbarkeit vielleicht.

Um Ihre Architektur skalierbar zu machen, benötigen Sie eine weitere Technologie, die Sie nicht erwähnt haben. - Sie brauchen Dienstleistungen. Ich würde WCF vorschlagen.

Wenn Sie Ihren BLL WCF-Dienst (oder mehrere Dienste) einrichten, wird Ihre Anwendung wesentlich effizienter und skalierbarer, sodass Ihr BLL auf verschiedenen Computern ausgeführt werden kann.