Mehrschichtarchitektur: Unterschichten und Datenmodelle

Geschichtete Anwendungsarchitektur: Untergeschichtenhierarchie und Datenmodelle

Die geschichtete Architektur strukturiert Anwendungen, indem sie Funktionalitäten in isolierte Schichten unterteilt: eine Fassade für den externen Zugriff, eine Logikschicht für Geschäftsregeln und eine Persistenzschicht für die Datenspeicherung. Jede Schicht gliedert sich in Unter-Schichten – Fassade, Logik und Datenzugriff –, was einseitige Interaktionen zwischen Schichten und bidirektionalen Datenaustausch zwischen Modellen ermöglicht.

Kernkomponenten einer Einzelschicht-Anwendung

Eine Einzelschicht-Anwendung vereint drei zentrale Funktionsgruppen:

• Geschichtete Funktionalität: Isolierte Schichten mit einseitigen Interaktionen zwischen benachbarten Schichten und Unter-Schichten.
• Querschnittfunktionalität: Gemeinsame Mechanismen, die allen Schichten zur Verfügung stehen, wie Logging oder Sicherheit.
• Datenflussfunktionalität: Datenübertragungsoperationen, darunter:

- Datenmapping, um zwischen Datenmodellen zu transformieren.

- Datenaufbindung, um Daten mit der Benutzeroberfläche zu verknüpfen.

- Daten-Serialisierung für den Austausch mit externen Systemen über Datenkanäle.

Schichtinteraktionen folgen einer strengen Hierarchie: Benachbarte Schichten tauschen Daten einseitig aus, während Datenmodelle bidirektional kommunizieren. Die Anwendung verbindet sich mit externen Verbrauchern (Datenverbraucher/-produzenten) über eine Eingabenschnittstelle und mit externen Datenquellen (lokal oder remote) via Ausgabeschnittstelle.

Lokale Datenquellen umfassen Dateien, USB/COM/LPT-Ports. Remote-Quellen beinhalten Datenbanken, FTP, LDAP, Webdienste und Message Broker.

Struktur von Schichten und Unter-Schichten

Jede Schicht enthält Funktionalitäten und zugehörige Datenmodelle. Unter-Schichten bestehen aus:

• Fassaden-Unter-Schicht: Externe API (öffentliche Methoden).
• Logik-Unter-Schicht: Interne Schichtlogik.
• Datenzugriffs-Unter-Schicht: Zugriff auf externe Quellen.

Beispiele für Interaktionen:

• Fassadenschicht: UI-Ereignisbehandler oder API-Endpunkte.
• Logikschicht: Koordiniert Geschäftslogik (Anwendungslogik).
• Persistenzschicht: Data Access Objects (DAOs).

Die Logik-Unter-Schicht der Fassadenschicht erzeugt UI-Inhalte (z. B. View-Templates in ASP.NET MVC) und Validierer (wie UniqueValueValidator, die über die Datenzugriffs-Unter-Schicht die Datenbank abfragen).

Die Logik-Unter-Schicht der Logikschicht implementiert Domänenlogik und interagiert mit der Persistenzschicht für Referenzdaten oder in rekursiven Algorithmen.

Externe Schnittstellen und Anwendungsgrenzen

• Obere Anwendungsgrenze: Gateway zu externen Verbrauchern via Eingabenschnittstelle (visuelle Formulare, serverseitige Sockets, Timer).
• Untere Anwendungsgrenze: Gateway zu Datenquellen via Ausgabeschnittstelle (Sockets, Datenbanktreiber).

Datenzugriff aus Fassaden-/Logikschichten:

• Direkt zu lokalen Quellen.
• Via Ausgabeschnittstelle zu remote Quellen.
• Über Persistenzschicht zu Datenbanken.

Die Persistenzschicht konzentriert sich auf Speicherung und Verwaltung persistenter Daten.

Architekturbeispiele

Strukturdiagramme zeigen den Einsatz in Webdiensten, Report-Viewern und ASP.NET MVC.

In einem Report-Viewer:

• Fassaden-Unter-Schicht: Visuelles Formular mit Report-Viewer-Komponente.
• Logik-Unter-Schicht: Report-Generator mit Vorlagen (Report-Templates) und Daten aus der Datenzugriffs-Unter-Schicht.
• Datenzugriffs-Unter-Schicht: Abfragen zur Persistenzschicht für Report-Daten.

Mehrschicht-Architekturen erweitern Einzelschicht-Architekturen: Jede Schicht ist eine geschichtete Anwendung und umfasst Client-Server, Event-Driven, Pipes and Filters, SOA und Microservices.

Wichtige Erkenntnisse

• Geschichtung (Fassade, Logik, Persistenz) gewährleistet Isolation und Skalierbarkeit.
• Unter-Schichten (Fassade, Logik, Datenzugriff) standardisieren APIs und Logik.
• Einseitige Schichtinteraktionen minimieren Abhängigkeitszyklen.
• Datenfluss (Mapping, Bindung, Serialisierung) optimiert Datenübertragungen.
• Klare Anwendungsgrenzen (Eingabe-/Ausgabeschnittstellen) trennen internen und externen Kontext.

— Editorial Team