|

Schichtenarchitektur

Der Schichtenarchitektur (engl. Layer architecture oder auch n-Thier-Architecture genannt) gliedert die Software in einzelne Schichten auf. Dieses Muster wird seit langer Zeit in der Softwareentwicklung angewendet und ist oft auch Grundlage für das Verständnis anderer Architekturen. Schichtenarchitekturen können nicht nur im Rahmen objektorientierter Entwicklung sondern auch zB bei der prozeduralen Programmierung eingesetzt werden (zB indem definiert wird, welche Prozeduren zu welcher Schicht gehören und man sich an die unten beschriebenen Regeln hält).

Zweck und Funktionsweise

Das Softwaresystem soll in horizontale Schichten aufgeteilt werden. Einzelnen Softwarekomponenten ist es je nach Art der Architektur gestattet, mit folgenden anderen Komponenten zu kommunizieren:

Komponenten, die sich in derselben Schicht befinden (horizontale Kommunikation)
Komponenten, die sich in einer direkt übergeordneten oder direkt untergeordneten Schicht befinden
Jede (außer die höchste) Schicht bietet Dienste für die übergeordnete Schicht an

Wieviele Schichten ein System hat und was die Aufgaben der Schichten sind, hängt von der zugrundeliegenden Problemstellung ab. Grundsätzlich spricht man bei n Schichten von einer n-Thier-Architektur.

Einführungsbeispiel

Eine typische Datenverarbeitungssoftware kann zum Beispiel aus folgenden 3 Schichten bestehen (3-Thier-Architektur):

Benutzeroberflächen-Schicht: Hier werden die Benutzersteuerelemente gerendert und die Oberfläche bereitgestellt
Geschäftslogik-Schicht: Hier werden Berechnungen durchgeführt und die Kommunikation zur Datenzugriffsschicht ermöglicht
Datenzugriffs-Schicht: Diese Schicht sorgt dafür, dass Daten aus der zugrundeliegenden Datenquelle (zB eine Datenbank) gelesen oder geschrieben werden kann.

In diesem Beispiel werden zB beim Laden eines Datensatzes durch den/die BenutzerIn folgende Schritte durchgeführt:

Die Benutzeroberflächen-Schicht gibt ein Signal, dass ein Datensatz angefordert wird an die Geschäftslogik-Schicht weiter
Die Geschäftslogikschicht leitet die Anfrage an die Datenzugriffsschicht weiter (und überprüft ggf. zB die Zugriffsrechte des Benutzers / der Benutzerin auf die angeforderten Daten, überprüft den Logikstatus, etc.)
Die Datenzugriffsschicht liefert die Daten aus der Datenbank und gibt sie an die Geschäftslogikschicht zurück
Die Geschäftslogikschicht leitet die Daten an die Benutzeroberflächenschicht weiter (und führt ggf. diverse Berechnungen aus - zB Summenbildungen, Aggregationen, Datenverknüpfungen, etc.)
Die Benutzeroberflächen-Schicht zeigt die erhaltenen Daten an

Dies mag im ersten Moment etwas umständlich wirken, aber stellen wir uns folgende Szenarien vor, um die Vorteile von Schichtenarchitekturen zu sehen:

Wenn das Datenbanksystem gewechselt wird, so muss nur die Datenzugriffsschicht angepasst/ausgetauscht werden. Die anderen Schichten arbeiten transparent weiter.
Es soll für eine bestehende Webanwendung eine alternative Benutzeroberfläche erstellt werden (zB eine Mobile-Variante). Dann ist die Erstellung einer weiteren Benutzeroberflächenschicht nötig. Geschäftslogik und Datenzugriffsschicht können aber weiterhin verwendet werden.

Varianten

Schichtenarchitekturen gibt es in allen Größen. Teilweise können sich bei großer Software hunderte Klassen in einer einzigen Schicht befinden (wobei man hierbei weitere Strukturierungslösungen innerhalb der Schichten designen sollte).

Eine Schicht kann aber auch nur aus einer einzigen Klasse bestehen. Zum Beispiel können die Datei Laden und Speichern - Operationen eines simplen Texteditors als eigene Klasse (Schicht) abgebildet werden, um für zukünftige Änderungen (zB verschiedene Datenpersistierungsarten) gewappnet zu sein.

Vorteile

Man verwendet Schichtenarchitekturen um:

Komplexe Systeme in einfachere Bausteine zu zerlegen ("divide and conquer")
Modulare Systeme zu designen (so sollen einzelne Schichten austauschbar sein)
Abstrakte Systeme zu designen (Änderungen in einer Schicht sind für andere Schichten transparent, sofern die Schnittstellen nicht verändert werden)

Nachteile

Folgende Nachteile können mit einer Schichtenarchitektur verbunden sein:

Höherer Implementierungsaufwand
Implementieren zu vieler Schichten für das aktuelle Problem (Antimuster: Lasagnencode)
Bei vielen Schichten müssen Daten durch alle Schichten durchgereicht werden. Dies führt teilweise zu zu komplexen und aufwändigen Vorgängen für triviale Operationen

Praxisbeispiele

Schichtenarchitekturen werden in den unterschiedlichsten Granularitäten verwendet. Sie können innerhalb einer einzigen Software, oder verteilt über mehrere Systeme angewendet werden. Traditionelle Datenverarbeitungssysteme sind oftmals in Schichten aufgebaut (zB ERP & CRM - Software). Ein weiteres Beispiel ist das TCP/IP - Modell (und dessen Implementierung) sowie das OSI Schichtenmodell zur Netzwerkkommunikation.

Abgrenzungen

n-Thier vs. MVC

Generell kann man sagen, dass die Schichtenarchitektur wesentlich grobgranularer entwickelt werden kann, als MVC. Die MVC-Architektur (oder das Pattern) kann bei großer Software als Implementierung für eine Benutzeroberflächenschicht einer Mehrschichtenarchitektur verwendet werden.

Beispiel: Viele Webapplikationen werden heute mit intelligenten Clients (=Verwendung von Javascript-Frameworks zB AngularJS) entwickelt. Dadurch kann sich zum Beispiel folgendes Szenario ergeben:

Benutzeroberflächen-Schicht: Die Website mit AngularJS umgesetzt als MVC-Pattern.
Client-Kommunikations-Schicht: zB clientseitige Angular-Services, die von den Controllern verwendet werden, um mit dem Webserver zu kommunizieren
Server-Kommunikationsschicht: MVC basierte Serveranwendung, die eine REST-API zur Verfügung stellt
Datenzugriffsschicht: Eigene Schicht zum DB-Zugriff auf dem Server

(Dieser Absatz muss noch weiter ausgeführt werden! Es sind zahlreiche Diskussionen im Internet darüber zu finden, zB http://stackoverflow.com/questions/4577587/mvc-vs-3-tier-architecture )

Hoch zum Inhaltsverzeichnis