Du kannst dir das DataLayer erheblich verk�rzen indem du Reflection verwendest. Du hast quasi im DataLayer eine Load(Type t, string Paramter) usw. Methode und �bergibts da dann den Book-Typ und eventuelle Parameter, und die DB gibt dir das passende Objekt zur�ck. Welche Werte von der DB in die Klasse wandern kannst du via Reflection rausfinden. Dazu gibt�s glaub auch nen Artikel auf ASPheute
-----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Pessner, Andreas Gesendet: Donnerstag, 11. November 2004 08:15 An: [EMAIL PROTECTED] Betreff: [Asp.net] 3 Schichtenmodell 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
