Das schon gelesen? Weiss aber nicht, obs gut ist... http://www.csharphelp.com/archives/archive211.html
Ansonsten stell ich mir vor, dass man die Properties der entsprechenden Klassen u.U. mit Attributen best�ckt, die das DB-Mapping beschreiben (so �hnlich wie hier: http://www.objectpersistence.com/) Und ich weiss nicht genau wie man das am besten in .NET realisiert, aber eine Idee w�re die komplette Objekt-Hierarchie vituell im Speicher zu halten... Objekte, die lange nicht genutzt wurden k�nnen aus dem Speicher gel�scht werden und wenn nicht vorhanden wieder eingelesen werden... Das ganze m�sste transparent passieren... Hat da jemand Ideen? Claudius > > Servus > > f�r ein neues Projekt in ASP.NET m�chten wir eine komplette 3-Tier > Anwendung theoretisch durchspielen. Dabei haben wir uns > entschlossen auf > jeden Fall voll objektorientiert zu arbeiten. > > Probleme haben wir bis jetzt nur beim Zugriff auf die > Datenbank. Bzw. es > ist klar, das wir einen "DB Manager" brauchen, der die Datenbank > kapselt. Als erste Datenbank haben wir nur "ACCESS" zur Verf�gung und > m�chten nun die Objekte in die Datenbank legen. > > Doch wie sollen wir das machen? Objektserialisierung k�nnen wir ja > prinzipiell vergessen, da wir dann immer die kompletten Objekte > rausholen m�ssen und am Ende wieder reinlegen... ich denke > das belastet > den Server zu stark. > > Also l�uft es doch wieder darauf hinaus, dass die Objekte in Tabellen > zerlegt werden m�ssen? Da wir aber nicht im Voraus wissen > welche Objekte > es gibt, m�ssen diese Objekte eigene Tabellen in der DB > anlegen k�nnen. > Das gibt ja ein heiliges durcheinander????? > > Das kann's doch nicht sein? Kennt sich da jemand aus und kann > uns einen > Tipp geben? > > _______________________________________________ > Asp.net mailing list > [EMAIL PROTECTED] > http://www.glengamoi.com/mailman/listinfo/asp.net > _______________________________________________ Asp.net mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/asp.net
