I've built a set of Query classes that allow for building a query for a particular persistent type using an OO API. As for relationships, I have a QueryFactory that produces the query necessary to resolve a relationship, but I don't automatically resolve any relationships because of the performance implications. It is left to the developer of the business class to decide when to load the related objects.
John -----Original Message----- From: Murphy, James [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 10:00 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] OT: Relational to Object mapping. Yes this is the basis for my current approach. GetValue/SetValue is likely not a great solution due to the degree of boxing involved. Shawn's idea of simply inheriting from DataSet is interesting. I assume that means wiring up set/get methods to access the data set itself? How about al the other facets of the problem like creating criteria in an abstract way and modeling relationships? Jim > -----Original Message----- > From: Sinnott, John [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 12:59 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] OT: Relational to Object mapping. > > > I also went down the route of using a descriptor class to > cache all the > FieldInfo instances per type. It was actually using > FieldInfo.SetValue()/GetValue() that turned out to be slow > for me. I agree > that it definitely seems like a more elegant solution, but in > my particular > case it was not. > > -----Original Message----- > From: Murphy, James [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 10, 2002 9:49 AM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] OT: Relational to Object mapping. > > The goal is to have all the specificity you want without > being invasive. > The persistent metadata for the class is orthogonal to the > class design. > > You can definitely get yourself into trouble if you do too much heavy > lifting with reflection APIs but I think this can be done > once per class > type and cached where necessary to offset performance problems. > > Since its early everything I've done has been single threaded. I'm > obviously interested to see what contention issues exist in > the reflection > classes. :-/ > > Jim > > > > > -----Original Message----- > > From: Sinnott, John [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 10, 2002 12:46 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET] OT: Relational to Object mapping. > > > > > > Not to say that your experience (or code) couldn't be better > > than mine, but > > I found in writing my own O/R mapper for .NET that reflection > > seemed fast > > enough when benchmarking a single thread, but when testing against a > > concurrent system, it became very slow. I switched instead > > to defining a > > persistent base class that stores its state in a hashtable. > > Invasive, yes, > > but much, much faster. It also allows for some more > > flexibility in what > > data gets loaded into an object. > > > > John > > > > -----Original Message----- > > From: Murphy, James [mailto:[EMAIL PROTECTED]] > > Sent: Friday, May 10, 2002 8:25 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET] OT: Relational to Object mapping. > > > > > 3. Fast and scalable > > > > > > *** I object - NOT with reflection. > > > > Oh - sure play the "Reflection is slow" card. You take a hit > > the first time > > the metadata is accessed but afterwards I've found its very > > adequate. Given > > the usage patter than a typical application will save and > > load a very finite > > set of class types the reflection performance problem isn't one. > > > > You can read messages from the DOTNET archive, unsubscribe > > from DOTNET, or > > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
