Mehrschichtige Architektur erklären

[nero.ch]

Hallo

Ich scheine den Begriff mehrschichtige Architektur nicht ganz zu verstehen. Die Vorteile sind mir bewusst (Wiederverwendbarkeit,...) lassen sicht leicht nachschlagen.

Nur kann ich mir das in der Praxis irgendwie nicht ganz Vorstellen.
Kann mir das jemand an einem ganz einfach Beispiel erklären?

Beispiel Videoverwaltung:
Wie baue ich die Präsentationsschicht (bsp. WebControls) unabhängig von der Buisiness Logik?
Ergeben sich dadurch 2 Projekte?

Links würden mir auch weiterhelfen. Nur habe ich bis jetzt nichts in diese Richtig gefunden wo es anschaulich erklärt wird.

[gfoidl]

Hallo,

Wie baue ich die Präsentationsschicht (bsp. WebControls) unabhängig von der Buisiness Logik?

Schau dir dazu am besten die MVC und/oder MVP an.

MVC...Model View Controler
MVP...Model View Presenter


mfG Gü

[fanderlf]

Es ist ja auch nicht wirklich UNABHÄNGIG von der Businesslogik. Das Ziel ist aber die Schnittstellen und Abhängigkeiten zu minimieren. Die Präsentationslogik muss mindestens die Schnittstellen zum Service Layer kennen um arbeiten zu können. Weil was soll sie denn auch tun, wenn sie gar nicht weiss was das Programm eigentlich macht.
Genauso läuft es vom Service Layer zum Datenbank Layer. Der Service Layer kann auch nur arbeiten, wenn er irgendwo Objekte persistieren und herholen kann.

Unabhängig davon hat Architektur eigentlich nichts mit aufteilen auf verschiedene Projekte zur Folge. Ich denke das ist eher die Folge einer guten Architektur.

Praktisch sieht das ungefähr so aus:

//Hier kommt alles rein was jeder Teil des Programms kennen muss
//Schnittstellen und Business Entitäten
//Zusätzliche kann (muss aber nicht) Funktionalität für die Business Entities hinterlegt werden.
// Hierbei darf es sich aber nur um Domänenlogik handeln (z.B. Funktion zum Ändern der Adresse des Kunden
MyProject.Common
*Referenziert:
*nur standardassemblies - keine Technikabhängigkeit
- Interfaces
+- ICustomerDataAccess.cs
+- ICustomerService.cs
+- IOrderDataAccess.cs
+- IOrderService.cs
- Entities
+- Customer.cs
+- Order.cs

//Hier kommt alles rein was man für Datenzugriff braucht
//Die Schnittstellen ICustomerDal und IOrderDal werden implementiert
MyProject.DataAccess
*Referenziert:
*MyProject.Common
- NHibernateCustomerDataAccess //implementiert ICustomerDataAccess
- NHibernateOrderDataAccess //implementiert IOrderDataAccess

//Hier kommt alles rein was Business Logik ist
//z.B. wenn der Kunde eine Bestellung ordert, dann versende eine EMail an die Versandabteilung und an den Kunden
MyProject.Services
Referenziert:
*MyProject.Common
*MyProject.DataAccess
- CustomerService.cs //ruft z.B. Addressänderungsfunktion auf - implementiert ICustomerService
- OrderService.cs //versendet z.B. EMails - implementiert IOrderService

//Behandelt die Use Cases aus dem Service Layer
//Bereitet Daten zur Anzeige auf
MyProject.Presentation
*Referenziert:
*MyProject.Common
*MyProject.Services
- Interfaces
+- ICustomerView
+- IOrderView
- PresentationModels
+- CustomerPresentationModel //Aufbereitete Daten für Anzeige
+- OrderPresentationModel
- CustomerPresenter //Kommuniziert mit ICustomerService
- OrderPresenter //Kommuniert mit IOrderService

//Hier werden nur die IViews implementiert
//Auf möglichst dumme Oberfläche achten, damit die ganze Sachen testbar bleibt
MyProject.WinFormsGUI
*Referenziert:
*MyProject.Presentation
- CustomerView.cs //implementiert ICustomerView
- OrderView.cs //IOrderView

Ich hoffe das hilft Dir etwas. Ich weiss auch, dass das ohne richtiges Projekt und in so einer Miniaturausgabe alles immer ganz einfach ist. Aber man muss es einfach versuchen. Spätestens nach dem 3. mal wird einigermaßen Hier hilft glaub ich nur: Learning by doing

Was ich noch dazu sagen kann: Man sollte sich nicht zu sehr auf vorgegebene Architekturmuster versteifen, sondern man sollte verstanden haben worum es geht. Das wichtigste überhaupt ist Separation of Concerns. Eine Klasse ist genau für eine Sache zuständig und macht auch nur diese eine Sache. Das ganze kombiniert mit sauberen Interfaces (die sollte es ja auch innerhalb eines Layer für bestimmte Bereiche geben) und Du bist auf dem richtigen Weg

[nero.ch]

Ok, vielen Dank für die Anregungen.
Muss mich mal damit genauer auseinandersetzen.

[gfoidl]

Hallo Florian,

super Antwort

Allerdings würde ich die Benamung in WinFormsGUI auch konsistent mit dem Namensschema der anderen Projekte halten. D.h. CustomerView und OrderView


mfG Gü

[fanderlf]

Ja da hast Du eigentlich recht. Habs oben auch gleich geändert. Bei uns heissen die einfach schon immer Frm... . Deswegen bin ich da etwas durcheinander gekommen. Die Macht der Gewohnheit

[gfoidl]

Hallo,

bekanntlich sind Bilder ja informativer als Text. Daher hab ich Florians-Projekt oben ein Schichtendiagramm erstellt -> siehe Anhang.

Das Bild zeigt auch schön wie die Zusammenhänge sind.
Quelle: MVVM (Model View View Model) Design Pattern for .NET Windows Forms (Winforms)


mfG Gü

[fanderlf]

Der Link ist sehr interessant Danke!!!


Wo Du die nur immer alle findest

[gfoidl]

Hallo Florian,

Wo Du die nur immer alle findest

Bookmarks


mfG Gü