Hallo Andreas Mir stellte sich die genau gleiche Frage und ich habe mal was angefangen, dass genau so aufgebaut ist wie Du es beschreibst. Bei mir funktioniert das so:
Es gibt einen "Kernel" den sog. DBProxy = Alle Methoden die DB Zugriffe machen. Es gibt "BusinessObjcts" welche die Objekte (in Deinem Beispiel Buch) beinhalten. Es gibt das Frontend GUI. Der Grund f�r diese Trennung liegt darin, dass die DBProxy seine Dienste �ber WebServices zur verf�gung stellt. Da WebServices keine wirklich komplexen Datentypen transportieren k�nnen, habe ich die "BusinessObjects" ausgelagert, damit das GUI dann diese DLL im eingene /bin Verzeichnis haben kann und somit diese Objekte benutzen kann. (Es mehrere Anwendungen/Projekte in unterschiedlichen Webs, welche die DBProxy benutzt) Anf�nglich war mein Plan, dass der Webservice mit z.B. GetBook(Id) ein Buch aus der DB holt und das BusineesObjekt "Book" zur�ckliefert. Allerdings geht das eben nicht (probleme mit Typen wie ArrayList). So liefert heute GetBook() ein Dataset mit dem Record des Buches. Je nachdem arbeite ich direkt mit diesem Dataset, oder ich verarbeite den Record und mache daraus ein "Book" Objekt. Dazu besitzt das modul "BusinessObjects" neben den Klassendefinitionen der BusinessObjects auch Methoden, die mir aus einem Dataset die entsprechenden Objekte "Book" erzeugen kann... Mittlerweile bin ich aber soweit, dass diese BusinessObjekte nicht mal so grossen Sinn machen. Sie verursachen mehr Aufwand, als dass sie nutzen birngen. Ich bin noch zwiegespalten. Einerseits ist es toll immer mit denselben Datenstrukturen (meine BusinessObjects) zu arbeiten, andererseits bietet ADO.NET mit dem DataSet eine sehr gute Alternative. UND - WebServices k�nnen problemlos DataSet's transportieren. So ist mein Erfahrungsstand, ich habe versucht nicht hoch akademisch, sondern pragmatisch und effizient vorzugehen. Zumal ich auch nicht Stunden in recherche und studium setzen konnte, sondern produktiv sein sollte... ;-) Patrik >-- Original-Nachricht -- >From: "Pessner, Andreas" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: [Asp.net] 3 Schichtenmodell >Reply-To: [EMAIL PROTECTED] >Date: Thu, 11 Nov 2004 08:14:56 +0100 > > >Ich habe eine Frage zum Projektaufbau von etwas gr��eren Projekten. > >Normalerweise sollte man ja die Applikation in 3 Schichten aufbauen! >1. Data Layer >2. Application Layer >3. Pr�sentation Layer > >Unter ASP konnte man das zwar versuchen - aber das war meist mehr oder weniger >schwierig umzusetzen. > >Unter ASP.NET sind dahingehend die M�glichkeiten nat�rlich deutlich besser >- auch wenn das wahrscheinlich die meisten Leute (ich eingeschlossen) noch >nie sauber voneinander getrennt haben - weil der Aufwand meist deutlich hinter >dem Nutzen zur�ck bleibt. Nun arbeite ich aktuell schon an gr��eren Projekten >- wo mir das mehr oder weniger immer wieder auf die F��e f�llt. > >Darum diese etwas philosophische Frage: Wie w�rdet Ihr das aufbauen? > >Gemeint ist: >Wo w�rdet Ihr welche Objekte einsetzen um die 3 Schichten miteinander zu >kommunizieren. > >Meine bisherigen Gedanken dazu: > >Der Data Layer sollte die gesamte Daten Logik enthalten. Das bedeutet das >er bestimmte Schnittstellen f�r den Applikation Layer hat - �ber die die >beiden Schichten miteinander typsicher kommunizieren k�nnen. >Im Data Layer sind aber nicht nur Methoden f�r die direkte Datenabfrage drin >- sondern auch Logik um diese typsicher f�r den Applikation Layer >vorzubereiten. > >Beispiel: >Buchladen - Datenhaltung in Datenbank (z.B.: MS SQL Server) > >DataLayer h�lt die Datenabfragen (Select, Insert, Update usw. bereit) >DataLayer baut Objekte vom Typ "Book" auf - die jeweils bestimmte Eigenschaften >haben (ID, Autor, Name usw.) >DataLayer hat Methoden f�r den Applikation Layer (Add, Remove, Store, usw.) >die typsicher immer nur �ber den Objekttyp "Book" laufen >-> Add(Book NewBook), Remove(Book Buch) usw. > >Damit kann man dann problemlos den DataLayer auch auf ein XMLSystem, CSVDatei, >Oracle DB, MySQL DB usw. umstellen. > >Wenn der DataLayer schon die Objekte hat k�nnte man nat�rlich im Applikation >Layer auch von Book erben und z.B.: StoreBook erstellen - welches dann noch >zus�tzliche Eigenschaften/Methoden hat. Damit m�sste man eigentlich fast >jeden Fall abdecken k�nnen. > >Ein Vorteil ist nat�rlich - das somit sicher gestellt ist - das man nicht >einfach "Book" im Applikation Layer erweitern kann - und sich dann wundert >- das die zus�tzlichen Daten gar net mehr gespeichert werden - da das ja >bei dem eigenen "StoreBook" ohnehin klar sein sollte! (falls man das �berhaupt >ben�tigt) > > >Nun stellt sich f�r mich die Frage ob es �berhaupt so gut ist - das der DataLayer >schon mit dem Objekttyp "Book" arbeitet. Weil dann m�sste man ja schon alle >ben�tigten Objekte im DataLayer halten. Denkbar w�re ja auch eine Kommunikation >�ber Typed DataSets. Diese k�nnte man ja auch im DataLayer sowie im Application >Layer universell einsetzen - auch wenn da jedes Mal eine Umwandlung notwendig >w�re - um wieder richtige Objekte zu erhalten. > > >Was meint Ihr zu dem Thema? Vielleicht habt Ihr ja auch mal ne Website - >wo man dieses Thema mal ausf�hrlich behandelt wird? (im Idealfall in Deutsch >;-)) > >Mit freundlichen Gr��en >Andreas > >_______________________________________________ >Asp.net Mailingliste, Postings senden an: >[EMAIL PROTECTED] >An-/Abmeldung und Suchfunktion unter: >http://www.glengamoi.com/mailman/listinfo/asp.net _______________________________________________ Asp.net Mailingliste, Postings senden an: [EMAIL PROTECTED] An-/Abmeldung und Suchfunktion unter: http://www.glengamoi.com/mailman/listinfo/asp.net
