Hallo,

ich habe mir die Tage die Webcasts von Patrick Lorenz angeschaut. Er erklärt ein wenig etwas über pragmatische Web Architektur. Sprich: die Trennung von UI-Layer, Business-Layer und Data-Layer.

Im zweiten Teil seines Webcasts (http://www.codezone.de/upload/PragmatischeWeb-Architektur_2_1911.wmv) legt er eine Klasse namens AppContext an. Diese soll bewirken, dass bestimmte Werte auf allen drei Layer zur Verfügung stehen sollen. Dieses ist z.B. dazu gedacht, dass ich einen Connectionstring aus der Web.Config einer ASP.NET Seite auch im Data-Layer abrufen kann.

Ich verstehe aber sein Vorgehen in Bezug auf dem AppContext überhaupt nicht. Könnte mir da jemand helfen?

Wenn du deine Frage etwas konkretisierts können dir da vielleicht auch Leute drauf antworten die keine Lust haben sich das Video anzuschauen

Nun ja das wird schwer aber ich versuche es mal.

In dem besagten Webcast geht Patrick Lorenz auf eine gute Programmarchitektur ein.

Dies macht er so, dass er die drei Hauptlayer erstellt: UI-Layer, Business-Layer und Data-Layer. Diese drei Ebenen greifen in folgender Reihenfolge aufeinander zu:

UI-Layer <----> Business-Layer <----> Data-Layer

Ebenfalls hat er noch ein Object-Layer erstellt in dem nur Getter und Setter sind und die später z.B. Daten aus der Datenbank speichern werden. Dieser Layer ist auf allen drei anderen Layer ansprechbar.

Das ist ja soweit alles klar. Jedoch kommt jetzt der Teil den ich gar nicht verstanden habe. Er hat im Business-Layer eine Klasse mit dem Namen "AppContext" angelegt. So wie ich es verstanden habe kann ich in dieser AppContext Klasse z.B. meinen Connectionstring oder auch Benutzerinformation hinterlegen kann. Diese Daten sollen dann angeblich auf allen Ebenen zur Verfügung stehen ohne das ich etwas als Parameter mitgebe. Diese gesamte Klasse bzw. Funktionsweise der Klasse verstehe ich nicht.

Leider kann ich das nicht besser veranschaulichen, sodass eigenltihc nur das Video Klarheit schaffen kann.

Das würde ich möglichst nicht so machen sondern alle Informationen die du benötigst durchreichen.

Eine Schicht sollte keine Abhängigkeiten in einer höheren Schicht haben. Das heißt das sieht so aus: PL->BL-DAL

Also wäre es sinnvoll hier ggf. in meinem object-layer eine klasse mit gettern und settern für settings bzw allgemein application infos zu erstellen und die dann zu füllen und weiter zu reichen über parameter?

Könntest du machen wenn es viele Parameter sind.

Wir hatten in einem größeren Asp.net Projekt auch einen Aufbau der dem von dir oben beschrieben wohl recht ähnlich war. Da gab es eine UserSession welche unter anderem den Connectionstring gehalten hat und dann überall benutzt wurde. Das hat auch alles wunderbar funktioniert. Das Problem war aber als wir später bei einem anderem Projekt ein paar kleine Teile davon rausziehen wollten um sie wiederzuverwenden brauchte man auch diese UserSession was dann wieder einen ziemlichen Rattenschwanz nach sich gezogen hat/hätte.

In einem späteren Projekt, was aber kein Asp.Net sondern Silverlight + WCF Sevices war haben wir das dann anders gemacht und den Connection String zwar auch am Principal (also im Prinzip wieder sowas wie die UserSession) gehalten, das aber nur in der obersten Schicht. Nach unten wurde er dann meist im C-Tor durchgereicht.

Das heißt wenn nun einer der Services in der obersten Schicht auf ein Bl Objekt zugreifen will muss er diesem beim anlegen den Connection String im Construktor übergeben.

Meistens fährt man am Besten damit wenn man die Dinge so einfach wie möglich gestaltet.