Gerade als Neueinsteiger hat man oft damit zu kämpfen, dass nach den ersten Erfolgserlebnissen der Quellcode schnell unübersichtlich wird, und scheinbar merkwürdige Fehler auftreten. Solche Probleme kommen dann oft beim Aktualisieren einer Benutzeroberfläche oder beim Aktualisieren der Daten vor, aber auch ganz allgemein bei der Anbindung von Datenbanken. Das scheint deshalb besonders demotivierend zu sein, weil erfahrene Entwickler offenbar nur sehr selten mit solchen Problemen zu kämpfen haben. Der Ratschlag lautet dann fast immer: Trenne deine Schichten! Warum man das tun sollte - und vor allem wie - versucht dieser Artikel zu erläutern.


Was sind Schichten?

In der Software-Architektur wird meist zwischen drei Schichten unterschieden, daher spricht man auch von der Drei-Schichten-Architektur. Jede Schicht ist dabei ein Programmteil, der in der Anwendung eine bestimmte Aufgabe übernimmt. Eine Schicht entspricht meist einem oder mehreren Projekten bzw. DLLs. Unterschiedliche Aspekte der Anwendung, wie beispielsweise Datenzugriff, Datenverarbeitung oder Benutzeroberfläche, werden dort jeweils unabhängig voneinander implementiert. Daher spricht man in dem Zusammenhang auch von der Trennung der Schichten. Durch fest definierte Schnittstellen zwischen den Schichten kann die jeweils höhere Schicht auf die darunterliegende(n) zugreifen, ohne etwas über deren speziellen Implementierung wissen zu müssen (siehe Bild).


Welche Schichten gibt es?

• Präsentationsschicht
  Die Präsentationsschicht (englisch: presentation layer) entspricht der Benutzerschnittstelle (englisch: [graphical] user interface, UI bzw. GUI) und übernimmt die Aus- und Eingabe der Daten. Hier befinden sich alle Funktionen zum Anzeigen der Daten auf dem Bildschirm (oder auf anderen Ausgabegeräten) sowie die Verarbeitung von Maus- und Tastatureingaben (oder anderen Eingabegeräten). Je nach Art der Anwendung kommen hier unterschiedliche Technologien zum Einsatz, so z.B. WinForms oder WPF für Desktop-Anwendungen sowie ASP.NET WebForms oder ASP.NET MVC für Web-Anwendungen.
  
  
• Logikschicht
  Die Logikschicht (englisch: logic layer, bussiness logic, BL) übernimmt die Verarbeitung der Daten. Hier werden alle anwendungsspezifischen Berechnungen implementiert und unter dem Begriff Geschäftslogik bzw. Businesslogik zusammengefasst. Als "Model" werden dabei alle Klassen bezeichnet, welche die Geschäftslogik beinhalten.
  
  
• Datenzugriffsschicht
  Die Datenzugriffsschicht (englisch: data access layer, DAL) übernimmt die Verwaltung der Daten. Hier befinden sich die Datenstrukturen zum Zugriff auf Datenbanken, XML-Dateien, Webservices, das Dateisystem o.ä.
  Kurz gesagt: alles, was mit dem Lesen und Speichern von Anwendungsdaten zu tun hat.

Was ist der Vorteil der Schichtentrennung?

Die Vorteile der Schichtentrennung ergeben sich durch die Vermeidung komplexer Abhängigkeiten. Die Präsentationsschicht ist beispielsweise nicht mehr abhängig von dem verwendeten Datenbanksystem, sondern kennt nur noch die Schnittstellen der Logikschicht und gelegentlich auch der Datenzugriffsschicht. Umgekehrt sind aber auch die beiden anderen Schichten nicht mehr von der für die Benutzerschnittstelle verwendeten Technologie abhängig.

Die Abhängigkeiten zwischen den Schichten wird auf eine fest definierte Schnittstelle reduziert, daher kann man die einzelnen Schichten unabhängig voneinander entwickeln, debuggen und testen. Sie können auch unabhängig voneinander weiterentwickelt oder sogar ausgetauscht werden, solange sich dadurch nicht die Schnittstelle zu den anderen Schichten ändert. Wird ein Programm beispielsweise von einer Datenbank auf einem Webservice umgestellt, dann muss lediglich die Datenzugriffsschicht neu entwickelt werden. Um eine Web-Anwendung auf eine Desktop-Anwendung umzustellen, muss im Idealfall nur die Präsentationsschicht ausgetauscht werden.

Somit ist die Schichten-Architektur nicht nur ein Weg, Programmfehler durch zu komplexe Abhängigkeiten zu vermeiden, sondern auch eine unumgängliche Voraussetzung für die Entwicklung von professionellen Software-Anwendungen. Daher ist die Schichtentrennung, besonders die Drei-Schichten-Architektur, heute ein üblicher Standard, der letztendlich eine effektive Softwareentwicklung im Team überhaupt erst ermöglicht.


Was ist der Unterschied zwischen einem "layer" und einem "tier"?

In der (englischen) Fachliteratur wird teilweise zwischen logischer und physischer Schichtentrennung unterschieden. Der englische Begriff "layer" steht dann für eine Schicht innerhalb einer Anwendung, also für eine logische Strukturierung von Elementen, die zusammen eine Software bilden. Sind die Schichten jedoch physisch auf verschiedene Rechner verteilt (also z.B. bei einer Server-Client-Anwendung), spricht man stattdessen von "tier". Daher unterscheidet man im Englischen zwischen Multilayered architecture und Multitier architecture.


Bild: Aufrufe in einer Drei-Schichten-Architektur

3 Anmerkungen

1. Mir fehlt total, dass auch auf Nachteile und Schwierigkeiten von 3-Schichten-Architektur eingegangen wird.
   Wie etwa, dass eine Menge "Glue-Code" zu schreiben ist, der eigentlich nichts tut, aber doch notwendig ist, die Schichten miteinander zu verbinden. Oft übertrifft die Menge des Glue-Codes sogar den eigentlichen Code um ein Vielfaches, wodurch die Wartbarkeit eher verschlechtert wird als verbessert.
   Auch erweisen sich viele Interfaces als sehr Aufwand-Trächtig, wenns drum geht, auf neue Anforderungen oder inhaltliche Verbesserungen hin die Architektur auch nur ein wenig umzustellen.
   
   
2. Auch wird hier überhaupt nicht auf Databinding geblickt
   Erfüllt Databinding die Bedingung, dass die Logik-Schicht nicht auf die Präsentations-Schicht zugreift? Bei einem gebundenen Control greift nämlich sehr wohl eine andere Schicht (ob sie nun "Logik" heißt oder wie auch immer) in die Präsentation ein.
   
   
3. Meiner Meinung nach wäre ein überzeugendes praktisches Beispiel sehr wünschenswert.
   So abstrakt als Forderung in den Raum gestellt, fühlt man sich leicht unter Druck gesetzt, und gleichzeitig in der praktischen Umsetzung allein gelassen. Dabei heraus kommen dann wohl gelegentlich recht abenteuerliche Konstruktionen, deren Autoren stolz sind, und denken, das sei richtig umgesetzte 3-Schichten-Architektur.

Hi ErfinderDesRades,

danke für deine Anmerkungen.

Zu 1: Stimmt, Planung und Umsetzung der Schnittstellen ist erforderlich. Aber die Planung und Umsetzung der eigentlichen Programm-Module wird dadurch wesentlich vereinfacht. Das bringt vor allem bei großen Projekten entscheidende Vorteile (Stichpunkt Teamwork), rentiert sich auch schon bei relativ kleinen Projekten, wie man hier im Forum oft sieht (also wenn z.B. direkt aus dem Code-Behind einer View eine Datenbank-Connection erstellt wird).

Zu 2: Databinding findet nur innerhalb der Präsentationsschicht statt. Die Trennung ist also leicht einzuhalten.

Zu 3: Ein praktisches Beispiel hätte ich auch gerne dazu erstellt. Nur hab ich das Problem gesehen, daß ein kleines Projekt die Vorteile nicht wirklich überzeugend darstellen kann, und ein großes Projekt einfach zu unübersichtlich wird. Falls du eine Idee hast, wie man ein hilfreiches Beispiel für Einsteiger in die Thematik aufbauen kann, bin ich gerne offen für Vorschläge.

Christian

Ich habe die Diskussion mal abgeteilt. Das wurde zuviel.

Die Diskussion zu dem Artikel findet sich her: Diskussion zum Artikel: Drei-Schichten-Architektur

Gruss

Coffeebean

Ich bin mit der Abteilung nicht uneingeschränkt glücklich, und empfehle sehr, die abgeteilte Diskussion auch wirklich zu verfolgen, denn es werden wesentliche zum Thema gehörige Fragen angesprochen, auch kontrovers, wie:

• Wann ist Schichtung empfehlenswert, und wann ist sie nicht empfehlenswert?
• Warum ist sie (wird vorwiegend vertreten) nahezu immer empfehlenswert?
• Warum findet man dann aber nirgends konkrete Beispiel-Projekte zum Download?

Die Überraschung (für manche zumindest): Es werden dann doch Downloads gegeben, sogar in Gegenüberstellung der Architekturen Ungeschichtet - Geschichtet (von letzterem inzwischen sogar noch weitere Variationen)
Die Beispiele sind überaus einfach, und die Schichtung mag in mancherlei Hinsicht unzureichend sein, aber in Anlage ist sie erkennbar, plausibel, und v.a. offensichtlich erweiterungsfähig.