Wann wird eine Anwendungsdienstschicht in eine n-Schicht-Anwendung eingeführt?

Ich entwickle eine webbasierte Anwendung, deren Hauptziel darin besteht, Daten aus der Datenbank abzurufen, auf der Benutzeroberfläche anzuzeigen, Benutzereingaben aufzunehmen und sie in die Datenbank zurückzuschreiben. Die Anwendung wird keinen Crunching-Algorithmus für die industrielle Stärke ausführen, sondern zu Spitzenzeiten (siehe unten), die sich im Laufe des Tages ändern werden, eine sehr hohe Anzahl von Treffern erhalten.

Die Ebenen sind Ihre typischen Präsentations-, Geschäfts- und Datenebenen. Die Datenschicht wird vom Datenbankserver übernommen. Die Business-Schicht enthält die DAL-Komponente für den Zugriff auf den Datenbankserver über TCP. Die Auswahlmöglichkeiten, um diese Ebenen in Ebenen zu unterteilen, sind:

1. Die Präsentations- und Business-Ebene können entweder auf derselben Ebene gehalten werden.
2. Die Präsentationsebene auf einer separaten Ebene für sich und die Business-Ebene auf einer separaten Ebene für sich.

Im Fall von Auswahl 2 wird die Präsentationsschicht von der Präsentationsschicht über einen WCF-Dienst entweder über http oder tcp aufgerufen.

Ich sehe keine schwere Verarbeitung auf der Business-Ebene, daher neige ich zu Option 1 oben. Aus dem gleichen Grund habe ich auch das Gefühl, dass das Hinzufügen einer neuen Schicht nur die Netzwerklatenz einführt. Was ist jedoch in Bezug auf die Skalierbarkeit für den Fall, dass ich skalieren oder verkleinern muss, ein besserer Weg? Diese Anwendung muss in der Lage sein, bis zu 6 Millionen Benutzer pro Stunde zu unterstützen. In jeder Benutzersitzung wird eine angemessene Datenmenge vorhanden sein, in der die Benutzereinstellungen und andere Details gespeichert werden. Ich werde auch Caching auf Seitenebene verwenden.

Ich würde Ihrer ersten Einschätzung zustimmen. Es ist wahrscheinlich nicht sehr sinnvoll, der Verarbeitung Ihres Systems einen zusätzlichen Netzwerk-Hop hinzuzufügen. Der Grund, warum Benutzer Ebenen physisch trennen, liegt in der anwendungsübergreifenden Wiederverwendung. Das heißt, Sie haben mehrere Anwendungen, die dieselben Dienste aufrufen, um einen Teil ihrer Arbeit auszuführen. Wie Sie bereits erwähnt haben, bietet die Business-Schicht nicht viel integrierte Logik. und bisher gibt es nur eine Anwendung, die es verwendet.

Es ist gut, dass Sie die Ebenen logisch getrennt haben, aber eine physische Trennung zu diesem Zeitpunkt könnte übertrieben sein.

Update, um Bedenken hinsichtlich der Skalierbarkeit auszuräumen

Ich würde immer noch argumentieren, dass es der beste Ansatz ist, die BLL auf derselben physischen Ebene wie die Präsentationsschicht zu halten. Sie können skalieren, indem Sie weitere Präsentations- / BLL-Knoten hinzufügen (bereits angesprochen, wenn Sie eine Fat Client-Bereitstellung verwenden, die für eine Webanwendung einfach genug ist). Auch wenn Sie feststellen, dass die Datenbank zum Engpass wird, unterstützen die meisten Datenbanken Clustering / Sharding und andere nützliche Tricks zum Skalieren. Erst nachdem ich beide Pfade durchlaufen habe (und natürlich verteiltes Caching hinzugefügt habe), würde ich versuchen, eine weitere physische Ebene hinzuzufügen.

Bevor Sie jedoch dorthin gehen können, würde ich versuchen, eine "herzhaftere" Geschäftsschicht als eine einfache Fassade für die Datenzugriffsschicht zu erstellen. Der erste Schritt besteht darin, ein leistungsfähiges O / RM zu verwenden, das die Datenzuordnung für Sie übernimmt. Dann sollten Sie Ihre Geschäftsobjekte intelligenter gestalten. Es gibt Unmengen von Papier über Domain Driven Design (das Buch ist ein guter Anfang). Wenn Sie die Schritte der Domänenmodellierung durchlaufen, begrenzte Kontexte definieren und aggregierte Wurzeln finden, können Sie eine Architektur mit natürlichen Nähten erstellen. Auf diese Weise können Sie Ihre Anwendung in eigenständige Dienste aufteilen, die bei Bedarf unabhängig voneinander skaliert werden können.

Ich gehe davon aus, dass Sie den Begriff "Tier" für einen physischen Server verwenden. Wenn Sie Ihre Geschäfts- und Präsentationsschicht nicht verteilen müssen, würde ich dies definitiv vermeiden. Das Senden von Objekten über den Draht ist teuer und anfällig für Probleme, die vermieden werden sollten. Sie sollten Ihre Architektur jedoch so gestalten, dass es einfach ist, weitere Ebenen hinzuzufügen, wenn sich das System weiterentwickelt und Überlegungen zum Design die Verteilung rechtfertigen. Ich in der Regel eine Anwendung entwickeln Service - Schichtals Klassenbibliothek / Assembly, die dieselbe Schnittstelle wie Ihr WCF-Dienst haben würde. Dies ist, was die Präsentationsschicht mit oder anderen externen Systemen verbindet. Wenn die Geschäfts- und Präsentationsebene nicht verteilt werden muss, verweist die Präsentationsebene direkt auf die Klassenbibliothek. Wenn sie verteilt werden müssen, ist Ihr WCF-Dienst nur ein dünner Wrapper um die Klassenschichtbibliothek der Dienstschicht, mit dem Sie remote auf den Dienst zugreifen können.

Ein Auge auf die Zukunft zu haben ist normalerweise eine gute Sache, aber die Einführung einer Service-Schicht oder irgendetwas wirklich, wenn eine nicht benötigt wird, kann jetzt nur noch Zeitverschwendung sein und Ihr System verlangsamen.

Die korrekte Aufteilung Ihres Systems in logische Ebenen ist auf jeden Fall eine gute Sache und ermöglicht es Ihnen, Ihr System zu einem späteren Zeitpunkt zu erweitern. Das Reduzieren der Kupplung wird dies in Zukunft einfacher machen.

Zufällig habe ich vor ein paar Jahren an einem großen System gearbeitet, das eine Website war -> Service-Schicht -> alles andere.

Die Service-Schicht wurde eingeführt, weil sich alle leitenden Architekten / Manager in SOA verliebt hatten, sodass unser System serviceorientiert werden musste. "Andere Systeme werden die Middle Tier-Funktionalität unserer Websites nutzen", lautete der Ruf.

Allein diese Entscheidung kostete das Projekt ein Jahr Verzögerungen.