Webseite - Mehrschichtsmodell und Interfaces

[rohamis7]

Hallo zusammen,

ich möchte eine Webseite erstellen, wo ich Daten aus einer DB hole (wie typisch ne?), seies es die Menüs oder einfacher Content.

Ich möchte/sollte dazu (zu Lernzwecken) das Mehrschichtsmodell anwenden (3 Schichten).

Also die Businesslogik (BLL), Datenzugriffsschicht (DAL + DB Klasse) und die GUI (aspx Seiten).

Da ich nun so viel darüber gelesen habe, wollte ich euch auch mal fragen, in wie fern das genau einen Sinn macht. Den grössten Sinn würde ich darin sehen, wenn man mehrere Seiten mit der selben Architektur erstellen möchte. Dabei sind diese Schichten so sehr automatisiert, dass man sie einfach für alle Projekte benutzen kann, egal wie die DB für die verschiedene Projekte aussieht.

Bei allen Beispielen bzw. Tutorials die ich gesehen habe, war das nicht der Fall. Jedes Modell ist der eigentlichen Webeite angepasst, d.h. ich kann das Mehrschichtsmodell von Webeite A nicht einfach in das Projekt der Webseite B reinpacken (bzw. nur die Verweise dazu) und es dann auch benutzen, unabhängig wie die Datenbank von Webseite B aussieht.

Also wie genau soll ich den Grund "mehrere Layer sind gut um die Austauschbarkeit zu garantieren" verstehen?

Zudem wollte ich euch noch fragen, in wie fern Interfaces mir nutzen könnten.

Danke.

[HJST1979]

Hallo

wenn die 3 Schichten ordentlich aufgebaut sind, sollte der Austausch GUI überhaupt kein Problem sein. Habe auch mein Privates Projekt in 3 Schichten aufgeteilt und kann ohne Probem die GUI austauschen, was ich auch tatsächlich gemacht habe (Austausch von winForms zu WPF). Dafür ist die GUI auch "DUMM", soll heißen die ganzen Prüfungen (ob z.B. bestimmte Werte gefüllt sind) habe ich auf die Businesslogik verschoben.

Schau dir dazu auch folgende Links an

Schichtenarchitektur

Three-Tier-Development

HowTo: 3-Tier / 3-Schichten Architektur | Code-Inside Blog

Gruß Hans-Jörg

[lbm1305]

@rohamis7

Hallo

wenn die 3 Schichten ordentlich aufgebaut sind, sollte der Austausch GUI überhaupt kein Problem sein. Habe auch mein Privates Projekt in 3 Schichten aufgeteilt und kann ohne Probem die GUI austauschen, was ich auch tatsächlich gemacht habe

Im Grunde genommen hast Du also nur ein Projekt, mit einer anderen GUI.

Das Problem ist, dass man eine Layer nicht so einfach in andere Projekte übernehmen kann. Ein Datenzugriffsschicht sieht für einen Webshop eben anders aus, als bspw. für eine Finanzsoftware.

Interfaces entkoppeln die Schichten voneinander. Damit bist Du flexibler im Austausch von Layern.

Beste Beispiel für ein Interface ist in meinen Augen die Datenzugriffsschicht.

Kunde A möchte Deine Software verwenden, nutzt als DBMS bspw. Oracle.

Kunde B hat aber eine MSSQL-Server.

Um eben flexibel zu bleiben, definiert man bspw. ein Interface IRepository mit dem man die CRUD-Befehle abbildet.

Wie nun die genau Implementierung aussieht, interessiert Dein Programm nicht.

[lilith2k3]

Der Aufbau in mehreren Schichten ist durchaus sinnvoll, vorallem in der Entwicklungzeit kannst Du davon profitieren:

Statt eine voll ausgearbeitete Datenbank hinter Dein Projekt zu klemmen reicht einfach ein Datenzugriffslayer, der bspw. auf Stub-Daten zugreift, oder wo auf ein ausgebautes Mock zurückgegriffen werden kann. Das heißt zum einen sparst Du Dir jede Menge Zeit (Zugriffe auf Stubs gehen eben schneller von Satten) zum anderen kannst Du schon entsprechende Funktionstests an Deiner Anwendung machen, ohne eine wirkliche Datenbank zu benutzen.

Darüberhinaus schafft die Abstraktion eines Datenzugriffslayers Dir die Möglichkeit, Dich unabhängig von einer konkreten Datenbank zu machen:

Du hast lediglich Deine Methode

DataAccessLayer.Get<Kunde>()

und den Rest braucht niemanden zu interessieren, was im Data Access Layer vor sich geht. Ob Du eine Flatfile-Datenbank, eine In-Memory-Datenbank, einen SQL-Server ansteuerst ist dann egal. Dein Programm arbeitet mit dem Objekt »Kunde« weiter.

Das Problem ist, dass man eine Layer nicht so einfach in andere Projekte übernehmen kann. Ein Datenzugriffsschicht sieht für einen Webshop eben anders aus, als bspw. für eine Finanzsoftware.

Jein. Kommt darauf an, wie gut man abstrahiert. Obige (generische) Methode ist letzlich der Aufruf, ein konkretes Objekt, mittels Data Access Layer zu beziehen. Und die Logik sieht da schon recht ähnlich aus (Daten beziehen, Daten deserialisieren und in ein Objekt packen, Objekt zurückgeben). Klar, dass es im Detail Unterschiede gibt, aber die sollten nicht wirklich in's Gewicht fallen. Kluges Design ist eben gefragt

Die Frage nach den Interfaces ist recht schnell zu beantworten:

Interfaces sind immer dann gefragt, wenn ich Objekte, die nicht von einander abgeleitet sind, mit gleichem Verhalten ausstatten möchte, also eine Familie aus ungleichartigen Objekten schaffen will. Beispiel:

Wir haben eine Klasse Fahrzeuge. Entsprechend können wir daraus die Klasse Flugzeuge ableiten lassen. Flugzeuge können fliegen.

Daneben haben wir beispielsweise Gänse. Gänse sind nun wirklich keine Fahrzeuge, aber Gänse können fliegen.

Will man nun eine Gruppe aus "Dingen, die fliegen können" schaffen, lagert man »Fliegen« in ein Interface aus.

Nun kann man bspw. über IFlying ableToFly nun sowohl Gänse als auch Flugzeuge ansprechen.

Oder anders: Interfaces erlauben eine Entkopplung von konkreten Objekten. Derjenige, der Interfaces definiert, definiert gleichsam einen Vertrag, den alle Objekte, die das Interface implementieren, als Minimum erfüllen müssen (ob sie darüber hinaus noch mehr tun, interessiert niemanden).

Das heißt, an der Stelle, an der ein Objekt mit entsprechendem Interface gefragt wird, wird tatsächlich lediglich eine Funktionalität erwartet.

E.g. hast Du ein Interface ILogging, welches eine Methode Debug(string message) vorsieht. Jedes Objekt, das dieses Interface implementiert, muss diese Methode implementieren. Ob in der Methode überhaupt etwas geschieht, ist nebensächlich. So kannst Du bspw. statt eines voll funktionsfähigen Loggers, einfach einen sog. "Null-Logger" übergeben, der zwar das Interface implementiert, aber nichts loggt. Das kann zu Testzwecken recht hilfreich sein.

[SilentDemise]

Siehe auch Repository Pattern.

[lilith2k3]

Siehe auch Repository Pattern.

Äh. Ja. Das ist dann die Kurzversion