Designfrage zu 3-tier-Application
Gottfried Lesigang
Ich grüble gerade über die beste Form der Kommunikation zwischen den
Ebenen meines 3-tier-Projekts...
Zentrales Element ist naturgemäß die Business-Schicht. Werden hier
Objektdaten verändert bzw. neue Elemente zu Listen hinzugefügt oder
entfernt, muss das irgendwie der Data-Schicht gesagt werden um das zu
persistenzieren.
Mir schwebt einerseits vor die Data-Schicht innerhalb von der
Business-Schicht zu instanzieren und über ihre Methoden anzusprechen,
irgendwie eleganter finde ich es aber jede Änderung in der
Business-Schicht per Event nach außen zu melden und die Data-Schicht
darauf reagieren zu lassen (um die Schichten noch unabhängiger zu halten).
Das GUI sehe ich im Sinne der auswechselbaren Skins: (fast) ohne eigene
Funktionalität, bloß ein grafisches Interface eben... Da wird es wohl
sinnvoll sein, die Business-Schicht intern zu instanzieren und ihre
öffentlichen Member zu modifizieren.
Gibt es dafür bewährte Patterns? Links?
mlg Gottfried
Jürgen Beck
news:3F808037...@web.de...
> Ich grüble gerade über die beste Form der Kommunikation zwischen den
> Ebenen meines 3-tier-Projekts...
> Gibt es dafür bewährte Patterns? Links?
Kennst Du die Microsoft Patterns & Practives?
"Patterns & practices provide proven architectures, production quality code,
and lifecycle best practices."
http://www.microsoft.com/resources/practices
Application Developers:
http://www.microsoft.com/resources/practices/Audiences.asp#dev
Enterprise Solution Patterns Using Microsoft .NET:
http://msdn.microsoft.com/practices/type/Patterns/Enterprise/default.asp
Enterprise Solution Patterns Using Microsoft .NET (.pdf Download):
http://download.microsoft.com/download/4/4/8/448e3308-1cde-49f5-9eb5-c6d0d9778670/ESP.exe
Jürgen Beck
MCSD.NET, MCDBA, MCT
www.Juergen-Beck.de
Gottfried Lesigang
mlg Gottfried
Herfried K. Wagner [MVP]
> Danke! Werde mich da mal vertiefen...
Und wenn das nicht reicht, dann das bekannte Buch von Martin Fowler:
<http://www.martinfowler.com/books.html#eaa>
--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Gottfried Lesigang
Habe mir die Microsoft-Artikel durchgelesen, bin aber zu meiner
eigentlichen Frage nicht schlau geworden...
Was ich da gefunden habe, kannte ich weitgehend schon. Ganz konkret
nochmal die Frage:
Wie lässt man die Layer am besten miteinander kommunizieren?
Ein möglicher Weg: Eine Instanz des Business-Layers (BL) besteht
innerhalb des Presentation-Layers (PL). Änderungen, die der Benutzer
über das GUI durchführt, werden intern direkt an die entsprechenden
Objekte des BL weitergereicht. Das PL ist somit wirklich nur "skin" des
BL, (fast) ohne eigene Logik. Genau so müsste das BL eine Instanz des
Data-Layers (DL) enthalten. In den diversen "Save"-Methoden des BL wird
dann das interne DL für die Persistierung (sagt man das so?) genutzt.
Anderer Weg: Per Interface könnte man die Layer zwingen, bestimmte
Events zu enthalten. Genau gegenteilig müsste dann das BL eine interne
Variable vom PL enthalten und auf dessen Events reagieren bzw. müsste
das DL eine Objektvariable vom BL enthalten um auf dessen Events zu
reagieren. Vorteil davon wäre eine noch klarere Trennung der Layers, da
der Code, der auf ein Layer "einwirkt" innerhalb dieses Layers
implementiert wäre. Einzige Schnittstelle wären dann die Events.
Ich hoffe mich klar ausgedrückt zu haben ;-)
Was haltet ihr für zielführender? Vielleicht stehe ich ja auch bloß am
Schlauch...
mlg Gottfried
Thomas Tomicek [MVP]
news:3F81AD26...@web.de...
> Danke für die Links!
>
> Habe mir die Microsoft-Artikel durchgelesen, bin aber zu meiner
> eigentlichen Frage nicht schlau geworden...
>
> Was ich da gefunden habe, kannte ich weitgehend schon. Ganz konkret
> nochmal die Frage:
>
> Wie lässt man die Layer am besten miteinander kommunizieren?
>
> Ein möglicher Weg: Eine Instanz des Business-Layers (BL) besteht
> innerhalb des Presentation-Layers (PL). Änderungen, die der Benutzer
> über das GUI durchführt, werden intern direkt an die entsprechenden
> Objekte des BL weitergereicht. Das PL ist somit wirklich nur "skin" des
> BL, (fast) ohne eigene Logik. Genau so müsste das BL eine Instanz des
Ja, so in etwa. "Fast ohne eigene Logic" bedeutet "mit nur der Logik die für
das Formular notwendig ist" Das kann z.T. ne ganze Menge sein (TreeViews
sind bekannt dafür ne Menge coe zu haben).
> Data-Layers (DL) enthalten. In den diversen "Save"-Methoden des BL wird
> dann das interne DL für die Persistierung (sagt man das so?) genutzt.
Nein.
* Wenn ein BLL-Objekt eine Save-Methode hat, brichst du fast alle Vorsätze
guter OO. Responsibility Pattern-Beachten.
* Es reicht, wenn alle BO's einer Transaction wissen wie sie einen
(gemeinsames) DataLayer ansprechen können. In unserem Framework eht das über
einen Manager (des BLL) den die alle referenzieren. Dieser erzeugt bei
bedarf (und konfiguriert (den DAL).
> Anderer Weg: Per Interface könnte man die Layer zwingen, bestimmte
> Events zu enthalten. Genau gegenteilig müsste dann das BL eine interne
> Variable vom PL enthalten und auf dessen Events reagieren bzw. müsste
> das DL eine Objektvariable vom BL enthalten um auf dessen Events zu
> reagieren. Vorteil davon wäre eine noch klarere Trennung der Layers, da
> der Code, der auf ein Layer "einwirkt" innerhalb dieses Layers
> implementiert wäre. Einzige Schnittstelle wären dann die Events.
Nein, ganz mies. Was sollte ein BL denn vom Frontend wissen? NIX. Schreibe
nie BLL abhängig vrom Frontend.
Folge guten OO prinzipien.
--
Regards
Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
Gottfried Lesigang
> Ja, so in etwa. "Fast ohne eigene Logic" bedeutet "mit nur der Logik die für
> das Formular notwendig ist" Das kann z.T. ne ganze Menge sein (TreeViews
> sind bekannt dafür ne Menge coe zu haben).
Na klar! Die Verwaltung der Ansicht kann ganz schön komplex sein...
> * Wenn ein BLL-Objekt eine Save-Methode hat, brichst du fast alle Vorsätze
> guter OO. Responsibility Pattern-Beachten.
> * Es reicht, wenn alle BO's einer Transaction wissen wie sie einen
> (gemeinsames) DataLayer ansprechen können. In unserem Framework eht das über
> einen Manager (des BLL) den die alle referenzieren. Dieser erzeugt bei
> bedarf (und konfiguriert (den DAL).
Das ist mir jetzt noch nicht ganz klar. Am Formular (GUI) befindet sich
ein "Speichern"-Knopf. Was passiert genau, wenn der gedrückt wird?
Ich dachte mir das so, dass die Business-Entities und die
Auflistungsklassen, zumindest aber eine Manager-Klasse des BL eine
"WriteToDB"-Methode haben, in der dann wiederum Methoden des DL
angsprochen werden. Oder habe ich da etwas grundsätzlich falsch verstanden?
> Nein, ganz mies. Was sollte ein BL denn vom Frontend wissen? NIX. Schreibe
> nie BLL abhängig vrom Frontend.
Leuchtet mir ein...
> Folge guten OO prinzipien.
Guter Tipp, nur etwas abstrakt ;-)
mlg Gottfried
Thomas Tomicek [MVP]
> Thomas, danke für deine Antwort!
>
> > Ja, so in etwa. "Fast ohne eigene Logic" bedeutet "mit nur der Logik die
für
> > das Formular notwendig ist" Das kann z.T. ne ganze Menge sein (TreeViews
> > sind bekannt dafür ne Menge coe zu haben).
>
> Na klar! Die Verwaltung der Ansicht kann ganz schön komplex sein...
>
> > * Wenn ein BLL-Objekt eine Save-Methode hat, brichst du fast alle
Vorsätze
> > guter OO. Responsibility Pattern-Beachten.
> > * Es reicht, wenn alle BO's einer Transaction wissen wie sie einen
> > (gemeinsames) DataLayer ansprechen können. In unserem Framework eht das
über
> > einen Manager (des BLL) den die alle referenzieren. Dieser erzeugt bei
> > bedarf (und konfiguriert (den DAL).
>
> Das ist mir jetzt noch nicht ganz klar. Am Formular (GUI) befindet sich
> ein "Speichern"-Knopf. Was passiert genau, wenn der gedrückt wird?
Der manager der busienss objects wird aufgeforder seine objekte zu sichern.
NICHT die Objekte.
Die sollten das nicht wissen.
> Ich dachte mir das so, dass die Business-Entities und die
> Auflistungsklassen, zumindest aber eine Manager-Klasse des BL eine
> "WriteToDB"-Methode haben, in der dann wiederum Methoden des DL
> angsprochen werden. Oder habe ich da etwas grundsätzlich falsch
verstanden?
Nein. Die MANAGER-Klasse hat das. Ist ja deren job. Aber nicht die einzelnen
objekte. Die haben kein delete, update, save, nix.
Geht alles über den Manager, und da reicht:
* Create (factory)
* Delete (markiere zum löschen)
* Commit
* Rollback
mehr brauchts nicht.
> > Nein, ganz mies. Was sollte ein BL denn vom Frontend wissen? NIX.
Schreibe
> > nie BLL abhängig vrom Frontend.
>
> Leuchtet mir ein...
>
> > Folge guten OO prinzipien.
>
> Guter Tipp, nur etwas abstrakt ;-)
Gud, hier ein konkreter rat: schreibe keinen code, kaufe ein Framework.
Gibt mittlerweise ne Menge gute O/R mapper draussen die dir den ganzen
schlamassel sparen - und einfach funktionieren. Wir haben auch einen.
Kostet monate sowas RICHTIG zu machen.