> > In our persistent framework, merely copying a object's > > properties doesn't cause objects to load, once on those > > properties is "dotted", that causes the object to be > > transparently loaded. It's sometimes a VERY efficient way to > > deal with objects, and sometimes not. When we're carrying > > lists of objects around, and only referencing some attributes > > of them, we don't load the other attributes (and related > > objects)--which is fast. When we do deref those objects, the > > get loaded (once per scope) in multiple transactions--which is slow. > > good point, lazy loading (or load on demand or whatever term is > correct) is indeed a way to load data 'on the fly' while you're not > aware of it. The point I was trying to make however was the initial > object data you start the 'dotted' traversal of relationship with, how > is that one loaded? -> you have to ask for it.
My gripe with lazy loading is that it causes the property accessor to block while data is retrieved. Generally such operations are slow(ish), so when you call: this.textBox1.Text = this.someBusinessObject.RelatedObject.SomeAttribute; The UI thread will block while the data is loaded synchronously. I'm not quite sure of when you should use properties vs. methods, but I always steer clear of putting 'long running' code in a property accessor. A user of my business model shouldn't have to worry about the fact that their request for a property might take some time to return. John. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
