Laden...

Trennung nach Layer vs. Trennung nach Modulen

Erstellt von Diräkt vor 9 Jahren Letzter Beitrag vor 9 Jahren 3.566 Views
D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 9 Jahren
Trennung nach Layer vs. Trennung nach Modulen

Liebe Leute 😃

Gerne würde ich Eure Meinung zu folgendem Thema erfahren:

Es handelt sich um eine grössere Web-Applikation welche auch in Zukunft gewartet werden soll:

Ist es besser dieses nach Layer zu trennen:

=> GUI
=> DAL
=> BL

oder nach Modulen

=> Modul1 (GUI;DAL;BL)
=> Modul2 (GUI;DAL;BL)

Überlegung:
=> Eigentlich kommen ständig neue Module hinzu, jedoch nicht neue Layers.
=> Wenn man nach Modulen trennt ist jeweils nur eine DLL bei einer Änderung betroffen und nicht gleich alle (DAL;BL;GUI)

Was sind Eure Überlegungen warum würdet Ihr das eine vom anderen "präferieren" ?

Beste Grüsse und besten Dank für Eure Inputs

Diräkt

2.207 Beiträge seit 2011
vor 9 Jahren

Hallo Diräkt,

deine Modulare Trennung beinhaltet ja auch die Trennung der Schichten. Somit stimmt der Titel nicht so ganz.

Ich gehe bei Webanwendungen (beispielsweise Angular) immer mehr den modularen Weg (auf dem Client). Das Hinzufügen und Wegnehmen von Modulen ist dann sehr einfach und hat keine Auswirkungen auf die anderen Module.

Natürlich gibt es auch Services (Server), die von mehreren Modulen genutzt werden können. Per DI stehen die einfach zur Verfügung und werden injected. (Ob man hier ein eigenes Projekt macht soll nicht Diskussionsrelevant sein). Die bilden dann schon eher eine komplette Schicht ohne Modularität.

Gruss

Coffeebean

16.806 Beiträge seit 2008
vor 9 Jahren

Bei einer Webanwendung hast Du heutzutage zwei Applikationen: Server und Client-Anwendung.
Server zum Beispiel ASP.NET MVC und Client AngularJS.

Das gute bei diesen Technologien: die Größe ist egal.
Bei ASP.NET bietet es sich sehr an, dass Du die Anwendung selbst von Logik und Datenbank trennst.
Bei mir sieht das meist so aus:

Server

  • ASP.NET MVC (zB auch Austauschbar durch statisches HTML und WebAPI), oder Redis zur Auslieferung von HTML
  • BL
  • DAL

Client

  • Angular
  • BL
  • DAL

Es kann gut sein, dass ich sowohl auf Server- wie auch auf Client-Seite die gleichen Entitäten benutze; daher arbeite ich hier mit TypeScript, sodass ich auch auf der Client-Seite vollständig typsicher arbeite und nichts doppelt machen muss.

Ob die Angular-App ihr HTML nun durch ASP oder das statische HTML über einen CDN bekommt: völlig egal. Es muss nur durch das Route-Modul spezifiziert werden.

Bei Angular selbst mach ich es wie Coffeebean, dass ich ganze Bereiche modularisiere.
Also das, was Du (früher) bei ASP.NET MVC durch Areas abbildest, bildest Du bei AngularJS eben mit Modulen ab.

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo Diräkt,

Module zu bauen, die GUI, BL und DAL in sich vereinen, halte ich wegen Separation of Concerns und Single-Responsibility-Prinzip nicht für sinnvoll. Das sollte schon getrennt werden/bleiben.

Aber es spricht nichts dagegen, in eine Schichtenarchitektur modular aufzubauen, also innerhalb der Schichten Module (oder Plugins) zu verwenden, siehe z.B. [FAQ] Eigene Anwendung pluginfähig machen.

Das Generic Manipulator Tool zeigt exemplarisch, wie man gui-unabhängige Plugins schreiben kann, die trotzdem definieren, welche Einstellungsmöglichkeiten dem Benutzer im GUI zur Verfügung stehen. Reine BL-Plugins, die vollkommen GUI-unabhängig sind, aber trotzdem Auswirkungen auf das GUI haben, sind also kein Widerspruch. Das wäre genauso für Auswirkungen auf den DAL denk- und machbar.

herbivore

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 9 Jahren

Danke für Eure Antworten Coffeebean, Abt und Herbivore.

deine Modulare Trennung beinhaltet ja auch die Trennung der Schichten. Somit stimmt der Titel nicht so ganz.

Module zu bauen, die GUI, BL und DAL in sich vereinen, halte ich wegen Separation of Concerns und Single-Responsibility-Prinzip nicht für sinnvoll. Das sollte schon getrennt werden/bleiben.

Die Modulare Trennung (weil die Module dann ja wirklich klein sind), würden gleich DAL,BL,GUI beinhalten, da gäbe es also "keine" Schichten-Trennung mehr. Auch ich sehe das als "schlecht" an, genau wie es herbivore schreibt. Behält man die Schichten aber bei wird dies meiner Meinung nach nicht wirklich übersichtlicher denn bei 30 Modulen hätte man ja bereits etwa 120 Projekte...
(DAL;GUI;BL;SERVICE)

Sind diese 120 Projekte nicht in der selben Solution wird auch Refactoring etc. nicht unbedingt einfacher...

Also sind wir eigentlich wieder bei der Einstiegsfrage nur kann ich diese nun hoffentlich etwas besser formulieren:

=> Bei einem System bei dem oft neue Module hinzukommen, an dem mehrere Entwickler arbeiten:

Ist es sinvoll die Applikation in 4 Layers zu trennen:
=> GUI; DAL; BL; SERVICE
oder wäre es tatsächlich "besser" diese nochmals zu unterteilen in
=> Modul1
=> GUI;DAL;BL;SERVICE
=> Modul2
=
> GUI;DAL;BL;SERVICE

(das die Module keine Schichten-Trennung mehr beinhalten sollen, lass ich gleich weg 😉)

Was meint Ihr ?

Beste Grüsse

Diräkt

742 Beiträge seit 2005
vor 9 Jahren

Ich würde gedanklich die Datei und Projektorganisation erstmal zur Seite schieben. Da gibt es viele Wege.

Bei heise developer gibt es einen guten Beitrag zum Thema Microservices mit einem klugen Gedanken: Es gibt einen starken Zusammenhang zwischen Architektur und Teamorganisation.

Angenommen du hast 20 Entwickler, die kleine Teams bilden. Dann könntest du zum Beispiel jedem Team die Verantwortung über sein Modul überlassen. Dann gehört in letzter Konsequenz aber auch dazu, dass das Team selber entscheiden kann, wann es deployen möchte. Sprich, du brauchst eine sehr flexible Architektur. Wir haben sowas teilweise gebaut und es hat sich sehr gelohnt. Ich kann dir aber keine allgemeinen Tipps geben, wenn ich die Anwendung nicht kenne. Es gibt auch einen interessanten Blog-Beitrag über die Architektur des Azure-Management-Portals, den ich gerade nicht finde.

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo Diräkt,

natürlich kann man nach Abwägung aller Gesichtspunkte zu dem Ergebnis kommen, dass es sinnvoll sein kann, sich über bestimmte Designregeln hinwegzusetzen.

Nach deiner Beschreibung sehe ich das jedoch nicht als sinnvoll an. Als es in einem unserer Projekte mal Performance-Probleme mit der Datenbank gab, waren wir sehr froh, wie einfach wir in unserem zentralen DAL ein Profiling einbauen/einschalten konnten. Wenn die Datenbankzugriffe auf x Stellen verteilt gewesen wären, wäre das viel mehr Aufwand gewesen und bei jedem neuen Modul hätten wir wieder neu ans Profiling denken müssen. Die einzelnen Modellklassen haben dem DAL im Wesentlichen nur Informationen über Tabellen- und Spaltennamen geliefert, waren aber unabhängig von der Datenbank.

Analog liefern auch die Plugins im Generic Manipulator Tool dem GUI nur Informationen, welche Einstellungen möglich sein sollen, aber enthalten keinen GUI-Code.

Es gibt also durchaus Möglichkeiten, GUI- und datenbank-unabhängige (BL-)Module zu schreiben. Ich würde die Schichtentrennung auch nach deinem Einwand nicht (leichtfertig) über Bord werfen.

herbivore

P
1.090 Beiträge seit 2011
vor 9 Jahren

Die Modulare Trennung (weil die Module dann ja wirklich klein sind), würden gleich DAL,BL,GUI beinhalten, da gäbe es also "keine" Schichten-Trennung mehr. Auch ich sehe das als "schlecht" an, genau wie es herbivore schreibt. Behält man die Schichten aber bei wird dies meiner Meinung nach nicht wirklich übersichtlicher denn bei 30 Modulen hätte man ja bereits etwa 120 Projekte...
(DAL;GUI;BL;SERVICE)

Du kannst die Schichten auch in einem Projekt erstellen. Die Schichten stellen erst mal eine logische Trennung da.

Eine Modularetrennung bietet sich an wenn wirklich keine Abhängigkeit zwischen den Modulen gibt. (Wo mit du aber wohl rechnest, was du ja in einem anderen Thread schon angedeutet hast.)

Ich würde dir erst mal eher zu einer Mehrschichtigen Architektur raten. Unter anderem weil ich denke, dass es leichter ist aus einer Mehrschichtigen Architektur, im zweifel Module zu extrahieren. Als z.B. 20 Module zu einer Mehrschichtigen Architektur umzubauen.

MFG
Björn

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

S
8 Beiträge seit 2015
vor 9 Jahren

Hallo,

hat jemand ein Beispielsprojekt wie man die Struktur (GUI;DAL;BL;SERVICE) sehen kann?

Gruß,

SehrScharf

M
233 Beiträge seit 2006
vor 9 Jahren

Hallo,

hat jemand ein Beispielsprojekt wie man die Struktur (GUI;DAL;BL;SERVICE) sehen kann?

Gruß,

SehrScharf

3-tier architecture in C#

ansonsten viele Tausende in der Suchmaschine deines geringsten Mißtrauens 😉
Suche nach : 3tier c# .net

S
8 Beiträge seit 2015
vor 9 Jahren

Ich kann aber das Beispiel niemandem empfehlen. BLL und DAL haben beidseitig Abhängigkeiten zu einander.

Trotzdem danke.