GUI, BLL, DAL - Was gehört wohin

Hallo,

ich möchte mal wieder ein Projekt in C# realisieren und dabei ordentlich die drei Schichten GUI, Business Logic Layer und Data Access Layer trennen.

Ich habe bereits gegoogled aber meist nur Forenbeiträge gefunden die immer wieder unterschiedliche Ansichten vertreten.
Daher möchte ich mich nun nochmal hier umhören.

GUI erscheint mir soweit klar: Die anderen Schichten kennen die GUI nicht, sondern die GUI ruft Funktionen aus dem BLL auf und abonniert Events vom BLL.

Ins Business Logic Layer kommt die eigentliche Programmfunktion und das Data Access Layer stellt den Zugriff auf die Daten bereit.

Nun soll es z.B. eine Klasse "Person" geben. Das Data Access Layer lädt die Daten aus einer DB oder einer Datei und das Business Layer soll mit dem Objekt Person arbeiten.
Aber wird die Klasse Person dann im Data Access Layer oder im Business Logic Layer definiert?

Gibt es überhaupt klare Definitionen/Vorschriften was in die einzelnen Layer soll oder implementiert das jeder ein bisschen anders?

Vielleicht hat auch jemand einen guten Link zu dem Thema wo die einzelnen Layer verständlich erklärt werden.
Da C# nur ein kleines Hobby ist möchte ich mir nur ungerne ein teures Lehrbuch anschaffen, wenn aber jemand hier einen heißen Tipp hat würde ich mich auch darüber freuen.

Lg Karoue

Aber wird die Klasse Person dann im Data Access Layer oder im Business Logic Layer definiert?

Das würde ich davon abhängig machen ob mit dieser Klasse hauptsächlich Datenbankaktionen passieren, oder ob sie eher andere Logikabläufe enthält. Sprich: Ist der Inhalt der Klasse eher auf Datenbankaktionen oder auf die Logik ausgelegt.

Du könntest auch alle derartigen Klassen in ein eigenes Assembly auslagern. Dann hast du eben eine weitere Schicht in deinem System die sich "Objektschicht" oder ähnlich nennen kann, sofern du dafür einen Namen finden musst.

Ist natürlich auch immer eine Frage der Größe deines Projekts, wie viele andere Programmierer beteiligt sind und wie sehr das Projekt "auf dem Papier" toll aussehen muss. Denn: Planung anhand einem strengen Schichtenmodell ist bis zu einem bestimmten Grad hilfreich, kann aber irgendwann auch alles verkomplizieren. Nämlich so wie bei dir, wenn du etwas nicht genau einordnen kannst und dann evtl. kuriose Umwege gehen würdest, nur um in die Theorie zu passen.

Danke erstmal für die Antwort!

Da ich das wie gesagt nur als Hobby betreibe muss auf dem Papier gar nichts gut aussehen und ich bin auch der einzige Programmierer. Allerdings wird das Projekt schon ein bisschen größer und soll vielleicht auch mal auf meiner Homepage herunterladbar sein.
Entsprechend möchte ich das ganze übersichtlich und gut wart- und erweiterbar programmieren. Da erschien mir die Aufteilung in diese Schichten geeignet.

Achso, wegen der Klasse Person:
Diese soll dann eigentlich keine Datenbankoperationen enthalten sondern nur direkt mit anderen Objekten arbeiten.
Entsprechend dann also wohl eher ins Business Layer nach dieser Argumentation. Erscheint dann eigentlich logisch, stimmt 😉
(Die Klasse Person war hier aber eh nur als Beispiel)

Hallo karoue,

ich würde hierbei aufpassen, dass du nichts vermischst. Natürlich kennen wir hier nicht die genauen Anforderungen von deiner Applikation.

Wenn du die Models in eine Assembly auslagerst, ist das sicher nicht schlecht. Wenn du jedoch beispielsweise Events oder Properties hast, die das Objekt im Business-Layer braucht, aber nicht direkt beim Datenzugriff verwendet werden, kann man drüber nachdenken das Ganze nochmal zu trennen. Somit bekommt der BL die Klasse Person, eventuell eben mit Events etc., und der DAL bekommt auch eine, aber ohne den ganzen SchnickSchnack, mit denen der BL arbeitet.

Chilic hat schon recht, dass es eben drauf ankommt. (Worauf, steht in seinem Post).

Auteilen könnte man das z.B. in "[BusinessLogik].Models" und "[DataAccessLayer].Models".

Viel Erfolg bei dem Projekt.

Gruss

Coffeebean

Hallo karoue,

ich würde dir auch raten, dass du dich nicht zu sehr darauf "versteifst", dass es nur die drei Schichten GUI/BL/DAL gibt. Ich empfehle hierbei immer eine Software wie eine Art große Maschine zusammenzubauen. Das bedeutet viele kleine Module (Klassen) bilden die Zahnräder und beim korrekten "zusammenstöpseln" drehen sich diese auch (hoffentlich). 😃
Wenn man sich daran hält und dann noch gruppiert nach der Funktionalität der Klassen so bilden sich daraus auch korrekt die Layer. Die Gruppen selbst kann man in einzelne Bibliotheken ausgliedern und somit schafft man eine saubere Übersicht als auch eine Austauschbarkeit der Komponenten. Das bedeutet aber auch Grenzen einzuziehen und Abhängigkeiten möglichst schwach (Stichwort Interfaces) zu halten.

Recht gut hierfür kann ich dir auch "patterns & practices" von Microsoft ans Herz legen.

Hoff es hilft dir weiter... Man lernt vor allem bei der Architektur durch Fehler und die unterlaufen jedem irgendwie und ich bin auch der Meinung, dass es DIE ultimative Architektur nicht gibt - da kommt immer wer der hält manchen Vorschlag für nicht sinnvoll und der andere schon. 😃

Viel Glück, Erfolg (und auch Spaß wenns ein privates Projekt ist).

lg

Vielen Dank für eure Antworten, das hilft mir auf jeden Fall weiter.

Dann werden ich es wohl wirklich nicht so genau nehmen und mich nur grob an den Schichten orientieren und wo nötig eventuell noch zusätzliches Einfügen.

Den Link von LatinChriz werde ich mir auf jeden Fall noch genau ansehen, danke!

Ich werden dann mal versuchen mir einen für meine spezielle Anwendung passenden Aufbau zu überlegen.

Über weitere Beiträge freue ich mich natürlich trotzdem 😃

HowTo: 3-Tier / 3-Schichten Architektur (C#)

Danke, der Link ist super!

Hier gibt es auch ein ganz guten Überblick: Layered Architecture for .NET