3 Layer Architektur wirklich sinnvoll?

[Oppirator]

Hallo Zusammen,

ich habe mein Thema jetzt mal in die Rubrik ASP gestellt, da ich gerade über so einer Anwendung sitze. Das Thema passt aber genau so auf Desktop-Anwendungen.

Ich stelle mir immer häufiger die Frage, ob es (noch) sinnvoll ist, Anwendungen in Client / Business und DataLayer zu unterteilen.
Warum stelle ich mir die Frage?

Bei nahezu jeder Anwendung reicht mein Businesslayer Entitäten nur vom Client zum Datalayer durch bzw. umgekehrt. Auch in Beispielanwendungen aus dem Netz passiert i.d.R. nichts anderes, als dass Entitäten weitergereicht werden.
Das Gegenteil sind Webanwendungen, in denen der komplette Businessteil bzw. auch der Datalayerteil in einer Webanwendung (einer Assembly) programmiert wird. Dies halte ich für weniger sinnvoll. Möchte man den Datalayer noch in einer Desktopanwendung verwenden, muss man den Code erst wieder mühselig trennen.

Von daher ist meine Frage, warum die normale Standardanwendung nicht lediglich in Client und Businesslayer unterteilt wird. Der Businesslayer wird bei mir i.d.R. mittels DependencyInjection in den Client gereicht. Der Businesslayer ist dann austauschbar, also für Mock oder Produktiv mit Speicherung der Daten z.B. im SQL-Server. Mein DbContext aus dem EntityFramework ist dann eben im Businesslayer und nicht im Datalayer enthalten. Es entfällt eine für mich unnötige Hierarchiestufe.

Mich würde von Euch interessieren, was hier gegen spricht. Die 3 Layer Architektur wird überall hervorgehoben. Warum ist das so?

Frank

[Christian Marquardt]

Mit einer 3 Schicht-Architektur könntest du die GUI austauschen. Bsp. von Desktop -> Web. Deine Geschäftlogik bräuchte nicht ersetzt zu werden. Ebenso könntest du die Persitenz von Datenbank auf XML umstellen. GUI und Geschäftslogik benötigten keine Änderung.

[Oppirator]

Vielen Dank für Deinen Beitrag.

Die Gui kann ich natürlich immer austauschen, egal, wie viele Layer dahinterhängen. Den bisherigen Businesslayer kann ich immer wieder verwenden.

Möchte ich die Persistenz von Datenbank auf XML umstellen, muss ich bei einer 2 Layer Architektur (Client / Business), den Businesslayer austauschen. Bei einer 3 Layer Architektur müsste halt der Datalayer ausgetauscht werden.
Eine Vereinfachung mit einer 3 Layerarchitektur sehe ich nicht.

[Christian Marquardt]

Eine Vereinfachung mit einer 3 Layerarchitektur sehe ich nicht.

Das hängt aber dann von ab, wie komplex jeweils deine Geschäftslogik und/oder deine Persitenzschicht ist. Wird die Geschäftslogik ev. in anderen Anwendungen genutzt usw.

Es gibt halt diese Architektur und sie hat sich als nutzbringend erwiesen

[Ralf Jansen]

Mich würde von Euch interessieren, was hier gegen spricht. Die 3 Layer Architektur wird überall hervorgehoben. Warum ist das so?

Weil es im allgemeinen Fall die erprobte Architektur mit denn meisten Optionen ist. Ob das in deinem konkreten Fall notwendig oder hilfreich musst du dir überlegen. Es ist nur ein Vorschlag und kein Gesetz.

Von daher ist meine Frage, warum die normale Standardanwendung nicht lediglich in Client und Businesslayer unterteilt wird. Der Businesslayer wird bei mir i.d.R. mittels DependencyInjection in den Client gereicht. Der Businesslayer ist dann austauschbar, also für Mock oder Produktiv mit Speicherung der Daten z.B. im SQL-Server. Mein DbContext aus dem EntityFramework ist dann eben im Businesslayer und nicht im Datalayer enthalten. Es entfällt eine für mich unnötige Hierarchiestufe.

Nötig ist keine der Hierarchie Stufen. Sie machen es aber immer einfacher eine saubere isolierte Architektur zu programmieren auch wenn man die gerade scheinbar nicht braucht. Wenn du genügend Sicherheit hast das das was jetzt gilt auch in der Zukunft gilt dann fände ich dein Vorgehen ok. Wenn man denn Lazy Character vom Entity Framework ausnutzen will hat man da auch Mühe die Schichten zu trennen. Aber die einfache Möglichkeit Persistenz und Logik räumlich zu trennen hast du dir für die Zukunft fast genommen (oder besser extrem erschwert). Wenn du EF mit POCOs verwendest würde ich wohl eher dahin tendieren weiterhin Persistenz und Logik zu trennen. Das sollte kein messbarer zusätzlicher Aufwand sein.

[tömmel]

Als Schmuddelkind sag ich's mal so: Programme gab's natürlich schon bevor es die Informatik als eigene "Wissenschaft" gab. Das ist noch nicht so recht überwunden und die Grenze zwischen Wissenschaft und Handwerk verschwimmt immer mal ganz gerne.

In der Physik rätseln die Theoretiker u.a mit Hilfe mathematischer Vorhersagen über den Inneren Aufbau der Materie - und jedesmal, wenn sie sich in ihrer Abschätzung verhauen, bohren die beim Cern einen größeren Tunnel (ist nicht von mir, hat ein eperimental Prof mal gesagt). Die Experimentaler basteln mit Ingenieuren an Detektoren bei denen zum Schluss der Elektriker irgendwo die Zeitung zwischen klemmt, das es funktioniert.Mir hat mal einer geagt: Sei froh, das Physiker keine Kernkraftwerke betreiben - zumindest nicht alleine....

Neben Wissenschaft und Handwerk, gibt es noch Theorie und Praxis....

Und aus der handwerklichen Praxis: Es ist meist unumgänglich und ungeheuer praktisch das Rad nicht ständig neu zu erfinden. Idealerweise implementiert man doch nur die Geschäftslogik - und egal welche Sau gerade durchs Dorf getrieben wird ergibt sich allein durch natürlich Faulheit und den zur Verfügung stehenden Werkzeugen und Bibliotheken ein Schichtmodell.

Sonst gibt es oft tatsächlich keinen Grund bei einem beinahe "Hallo Welt" Programm soviel Overhead zu erzeugen - und oft ist das eigentliche Problem wirklich nahezu trivial - man machts trotzdem, weil gut getesteter Code schon vorhanden ist...

Das man vom Web auf den Desktop zieht (oder umgekehrt) - und alle zufrieden sind und wirklich nix umgedödelt werden muss ...naja hab ich mal gehört. Nur wenn der Aufwand um das zu können groß ist - man aber nicht die Notwendigkeit dazu hat, dann

[fanderlf]

Ich bin einfach dafür Sachen die nicht zusammen gehören zu trennen. Dann hast Du an manchen Stellen vielleicht 3 Schichten. Bei manchen der Einfachkeit halber eben nur zwei und manchmal auch mehr. Das Beste ist es die Geschäftslogik möglichst frei von Technik zu halten. Und natürlich sollte auch kein DB Statement direkt im Controller ausgeführt werden. Ansonsten bin ich kein Freund von Architekturen die man nur deswegen macht damit man diese Architektur hat. Das sind dann meistens die Stellen Code an denen man in 2 Jahren wieder vorbei kommt und man sich fragt warum um himmelswillen man selbst das damals so umständlich programmiert hat.

Ausserdem bin ich auch ein Freund des "pragmatischen kopierens". Hier und da schadet es nicht ein kleines Stückchen Logik mal zu kopieren, wenn dadurch die Architektur wesentlich leichter wird. Oft werden Anwendungen übertrieben generisch DRY programmiert. Dann hab ich zwar tatsächlich jedes Stückchen Code nur einmal, aber a, kann ich das Teil nie wieder anfassen weil alles so miteinander verwoben ist dass ich bei der kleinsten Änderung irgendwelche Stellen in der Anwendung breche und b, der Code dann meistens so unleserlich wird das ich Würgereiz bekomme wenn ich das nächste mal hineinschaue.

[Oppirator]

Vielen Dank für Eure Beiträge.

Frank