Schichten-Trennung bei 3 Schichten

Ich habe Fragen zum 3-Schichten-Modell:
Wie trennt man eigentlich die 3 Schichten? z.B. über unterschiedlichen Namespaces?
Und wie verbindet man sie? z.B. über Methodenaufrufe?

Irgendwie habe ich das Gefühl, dass man gerne über das Modell spricht, nicht aber über die Umsetzung. Was ich bisher gefunden habe, sind Aussagen "Das Projekt ist zu groß, als dass man es hier zeigen kann". Einfache Beispiele habe ich bisher nicht gefunden.

Bei meinem Anwendungsbeispiel wäre
Datenzugriffsschicht = Definition der Objektlisten + Serialisierung
Präsentations-Schicht = Definition von DGV, Combo, Buttons usw. einschließlich Eigenschaften und Eventhandler-Aufrufe
Logikschicht = Durchführung der Eventhandler, rechnen, und alles, was sonst noch übrig ist.

Dazu haben wir einen Artikel.
[Artikel] Drei-Schichten-Architektur

Ansonsten kannst du die Trennung durch eigene DLLs umsetzen oder auch über Namespaces.
Durch die harte Trennung über DLLs wäre ein falscher Zugriff z.B. von der UI direkt auf den Daten Schicht ausgeschlossen.
Hier müsstest du dann die DLLs bis zur UI auch ensprechend referenzieren.

Eine Trennung durch Namespaces wäre auch möglich z.B. bei kleinen Projekten wo sich der Aufwand für die harte Trennung kaum lohnt.
Dann musst du nur auf die jeweiligen Klassen in der richtigen Reihenfolge zugreifen.

Wichtig dabei ist, dass jede Ebene ihre eigenen Modelle hat.
Z.B. hast du in der Datenschicht die Entitäten, die deine vollständigen Datenmodelle oder Teile davon (Projektionen) davon darstellen.
Auf der Anwendungsschicht/Business Layer, hast du dann eine Business Objekte.
Diese können dann je nach Form einzelnen oder zusammengesetzten Entitäten entsprechen.
Und ganz oben hast du dann deine View Models, die für die jeweilige Ansicht gedacht sind (Detail- oder Listen Ansichten)

Zwischen den Ebenen musst du dann die Daten durch reichen.
Also von den Entitäten an die Business Objekte und von denen an die View Models.

Nachtrag:
Passend dazu auch noch der Wikipedia Artikel zu dem Thema:
Schichtenarchitektur

T-Virus

Hallo kstanger,

bei dem Thema wo es ums Verständnis geht helfen vllt. mehre Antworten mit ähnlichem Inhalt, aber verschiedenem Text 😉

Der Vollständigkeithalber: [Artikel] Drei-Schichten-Architektur

Einfache Pauschalantworten auf deinen Frage kann ich nicht geben, da es wie so oft abhängt, worum es konkret geht. Ich versuch daher verkürzt und vereinfacht zu antworten.

Wie trennt man eigentlich die 3 Schichten?

Bei kleinen Projekten: verschiedene Namespaces
Umso größer das Projekt wird, so desto eher erfolgt auch eine Aufteilung in verschiedene Projektmappen (csproj).
Möglichkeiten gibt es viele, die aber vom konkreten Fall abhängen.

Und wie verbindet man sie? z.B. über Methodenaufrufe?

Wenn alles im gleichen Prozess läuft, dann ja. Einfacher und besser geht es nicht.
Sind die Schichten über mehrere Prozesse verteilt, so wird IPC (inter process communication) benötigt und falls die Schichten gar auf mehreren Servern verteilt sind, dann eine andere Kommunikationsart.

über das Modell spricht, nicht aber über die Umsetzung.

Ich sehe dafür merhere Gründe (auch wenn ich zurück an meine Anfangszeiten denke):* Es gibt nicht "die Umsetzung" da es je nach konkreter Anforderung verschiedene Ausprägungen geben kann. Sowie es in der (Bau-) Architektur auch nicht "die Umsetzung" vom Haus gibt. Grundsätzlich schon (Keller, Parterre, Obergeschoße), aber konkrete hängt es auch hier vom Anwendungsfall ab.

• Die 3-Schichten Architektur ist trivial -- da gibt es nicht sehr viel zu beschreiben.
  Mir gings aber auch so, dass die geistige Hürde fürs Verständnis erst einmal übersprungen werden musste. Am einfachsten gehts mit einem ganz simplen Projekt, bei dem Unit-Tests vorhanden sind, denn die Testbarkeit von Komponenten führe mehr od. weniger automatisch zum richtigen Design.

Datenzugriffsschicht = Definition der Objektlisten + Serialisierung

"Serialisierung" für was? Nimm besser ein Datenbank statt in Dateien zu Serialisieren.

mfG Gü

Wie trennt man eigentlich die 3 Schichten? z.B. über unterschiedlichen Namespaces?

Grundlagen Namespaces: Organisieren von Typen in Namespaces
Namespaces sind kein Mittel der Architekturtrennung, sondern der Organisation von Typen.

Sieht man also sowas wie "MyProject.DAL" dann weiß man: derjenige hat nicht verstanden, worums geht - oder reiner Pragmatismus.
Letzteres funktioniert wenn überhaupt aber nur in kleinen Projekten.

-> gfoidl

• Den Artikel kenne ich schon länger; deswegen habe ich auch die Bezeichnungen der Schichten genauso gewählt.
• Serialiserung nehme ich, weil es ein sehr kleines Projekt ist. Wenn ich eine Datenbank nehmen würde, dann müsste ich z.B. die Datenbank auch mit auf einen anderen Rechner übertragen, oder?

Nein, es gibt Portable Datenbanken wie SQLite….

Kann ich die im Projekt erzeugen?
z.B. Wenn Datenbank nicht vorhanden, dann erzeuge sie und fülle sie mit Startwerten.

Schau dir das Tutorial in den MS Docs dazu an. Deswegen ist es da.
Ist dort alles erklärt. Wenn du dann noch fragen hast, dann wieder melden 🙂