> > > 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.
True, however with lazy loading you only have this hit once. See
it as if you bind some collection with entity objects to a datagrid and
the user navigates through the object model, in fact walking
relationships. This is then possible through lazy loading which loads
the objects only once.
But I agree with you that if you have to walk some objects to
get a desired collection (like (silly example)
Customer.Orders[0].Products), perhaps it's more wise to construct a
small query to retrieve the collection directly so you avoid fetching
all intermediate collections (Customer.Orders[0] fetches all orders of
Customer, and you only use 1, the 0-index :) ) separately, which indeed
can take some time.
It's the hidden price of Lazy loading (or load on demand) which
is definitely not obvious when you walk through a set of properties (and
it's generally 'easier' to walk the properties than to construct a
query). I've implemented the real fetching code as methods which are
accessed also by the properties, however I can't do it any other way,
because a bound control like a datagrid will not access methods but will
access properties only, so the properties have to be there.
FB
===================================
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
