Drei-Schichten-Architektur – warum trennt man Oberfläche, Logik und Datenhaltung überhaupt?

Die Frage ist gut, weil der Nutzen erst sichtbar wird, wenn man sich das Gegenteil vorstellt 🙂 Erst die Zuordnung, die du in der Klausur brauchst:

• Präsentationsschicht: alles, was der Nutzer sieht und bedient – im Web also der Browser mit HTML/CSS/JavaScript, in der Firma die Desktop- oder Mobile-Oberfläche.
• Anwendungs- oder Logikschicht: die fachlichen Regeln und Abläufe – Preisberechnung, Rabattprüfung, Bestellprozess. Läuft auf dem Web- bzw. Applikationsserver.
• Datenhaltungsschicht: das Datenbankmanagementsystem, das speichert, sucht und die Konsistenz sichert.

Die entscheidende Regel dabei: Jede Schicht spricht nur mit ihrer Nachbarschicht. Die Oberfläche fragt die Logik, die Logik fragt die Datenhaltung – die Oberfläche redet nie direkt mit der Datenbank.

Und genau daraus kommt der Nutzen:

• Austauschbarkeit: Neue Oberfläche, etwa eine App zusätzlich zur Website? Die Logik bleibt, du tauschst nur oben. Umzug auf ein anderes Datenbanksystem? Du tauschst nur unten.
• Mehrfachnutzung: Website, App und Partnerschnittstelle nutzen dieselbe Logik – die Regel existiert einmal statt dreimal.
• Sicherheit: Die Datenbankzugangsdaten liegen auf dem Server, nicht beim Client. Beim Zwei-Schichten-Modell (klassischer „Fat Client“, der selbst SQL absetzt) hat jeder Arbeitsplatz effektiv einen Datenbank-Schlüssel in der Tasche.
• Skalierung und Arbeitsteilung: Bei Last stellst du gezielt Applikationsserver dazu, und im Team kann an Oberfläche und Logik parallel gearbeitet werden.

Ergänzend der Punkt, über den in Klausuren am meisten gestolpert wird: Schichten sind etwas anderes als Rechner. Die drei Schichten sind eine logische Aufteilung der Software. Wie viele Rechner daran beteiligt sind, ist die physische Verteilung – dafür sagt man meist „Tiers“.

Heißt konkret: Wenn du eine Anwendung mit sauber getrennter Oberfläche, Logik und Datenhaltung komplett auf deinem Laptop laufen lässt, ist das trotzdem eine Drei-Schichten-Architektur – nur eben auf einem einzigen Rechner. Umgekehrt macht das bloße Verteilen auf drei Server aus einem Programm noch keine saubere Schichtung.

Und weil in Aufgaben gern nach Nachteilen gefragt wird – die gibt es nämlich auch:

• mehr Kommunikation über Schichtgrenzen hinweg und damit zusätzliche Latenz,
• höherer Entwicklungs- und Betriebsaufwand, mehr Komponenten zu überwachen,
• bei schlecht geschnittenen Schichten muss man für eine Kleinigkeit trotzdem alle drei anfassen.

Der Standardnutzen (Wartbarkeit, Austauschbarkeit, Sicherheit) überwiegt bei größeren Systemen deutlich – für ein Ein-Personen-Skript wäre die Trennung Overkill. Genau diese Abwägung ist meist die erwartete Antwort.

Aus der Praxis noch das Beispiel, das es bei uns im Team endgültig klick gemacht hat: Regel im Shop – „Rabatt über 20 % nur mit Freigabe durch den Vertriebsleiter.“

Liegt diese Prüfung in der Oberfläche, dann gilt sie nur für Leute, die über die Website bestellen. Sobald die App, ein Import aus dem Außendienst oder eine Partnerschnittstelle dazukommt, läuft der Rabatt daran vorbei – und keiner merkt es, bis die Marge nicht mehr stimmt. Liegt sie in der Logikschicht, gilt sie für alle Wege, weil alle durch dieselbe Tür müssen.

Als Merksatz für die Prüfung: Die Oberfläche fragt, die Logik entscheidet, die Datenhaltung erinnert sich. Wenn du bei einem Beispiel unsicher bist, welcher Schicht etwas gehört, frag dich, ob es eine fachliche Entscheidung ist (dann Logik), eine Darstellungsfrage (dann Präsentation) oder eine Speicherfrage (dann Datenhaltung). Damit kriegst du fast jede Zuordnungsaufgabe hin.