Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
[Artikel] Drei-Schichten-Architektur
MrSparkle
myCSharp.de - Team

Avatar #avatar-2159.gif


Dabei seit:
Beiträge: 5967
Herkunft: Leipzig

Themenstarter:

[Artikel] Drei-Schichten-Architektur

beantworten | zitieren | melden

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
Attachments
Weeks of programming can save you hours of planning
private Nachricht | Beiträge des Benutzers
ErfinderDesRades
myCSharp.de - Experte

Avatar #avatar-3151.jpg


Dabei seit:
Beiträge: 5409

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von ErfinderDesRades am .
Der frühe Apfel fängt den Wurm.
private Nachricht | Beiträge des Benutzers
MrSparkle
myCSharp.de - Team

Avatar #avatar-2159.gif


Dabei seit:
Beiträge: 5967
Herkunft: Leipzig

Themenstarter:

beantworten | zitieren | melden

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
Weeks of programming can save you hours of planning
private Nachricht | Beiträge des Benutzers
Coffeebean
myCSharp.de - Team

Avatar #avatar-3295.gif


Dabei seit:
Beiträge: 2459
Herkunft: Deutschland/Schweiz

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
ErfinderDesRades
myCSharp.de - Experte

Avatar #avatar-3151.jpg


Dabei seit:
Beiträge: 5409

beantworten | zitieren | melden

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.
Dieser Beitrag wurde 6 mal editiert, zum letzten Mal von ErfinderDesRades am .
Der frühe Apfel fängt den Wurm.
private Nachricht | Beiträge des Benutzers