Not too lazy my friend.

In previous posts I've written about how I believe being lazy makes me a better programmer.  Today I'm going to talk about how using lazy objects can have a counter affect.  In many of the applications that I write I have properties that are lazy loaded.  A lazy loaded property starts out as null, and upon the first access to the property the value is retrieved from the data store.  This can help reduce the load on the database server and can help ensure we only access the data that is necessary. 

If your not careful with lazy loaded properties you can quickly run into trouble.  This past week I was investigating a performance problem in a section of an application that was utilizing objects with lazy loaded properties.  To make a long story short the lazy loaded properties were causing an extra database hit for every row of data that was being displayed on the screen. 

To tie this into a couple of my recent posts on Domain Driven Design let me state that although I'm not sure it would have prevented the problem, I think had I created repositories for the aggregates within my application I would have avoided the problem.  Rather then allowing my objects to retrieve data from the database I should have had everything go through a repository.  This prevents our objects from running a-muck.  Our repositories can control exactly what is and isn't returned, and we reduce the risk of our objects going nuts with database calls.

Beware of the lazy loaded properties!

# RE: Not too lazy my friend.

Tuesday, August 17, 2004 11:41 PM by Eric Wise    
I've struggled with trying to find the right balance of lazy load with traditional loading and I've fallen into the following pattern:

If it is a client calling a server/webservice, I want as few database calls as possible.

If it is a server calling a server (like my webserver talking to the sql server sitting next to it) then I am more apt to lazy load.

Maybe this is the "right" way, maybe it isn't. At this point only time and experience will show me.

# re: Not too lazy my friend.

Wednesday, August 18, 2004 1:43 AM by Steve    
Another important thing to keep in mind is how the objects are being used. In my particular instance the web and database servers where sitting right next to each other, however, adding a 100 extra database calls wasn't doing a lot to increase performance. It's important to keep in mind how your objects are going to be used and make sure everyone is on the same page regarding the implications of using the objects with their default (lazy loaded) behavior. On pages that will always need the properties that are setup for lazy loading, we should load them upon object creation with a single (or close to it) call to the database.

# Lazy Reads - a structured approach

Thursday, August 19, 2004 2:09 AM by Steve Hebert's Development Blog    
Lazy Reads - a structured approach

# re: Not too lazy my friend.

Thursday, August 19, 2004 5:02 AM by Steve Hebert    
Hi Steve, this is a great topic. It reminded me of a project I was on where I used lazy reads extensively. I blogged it at <a target="_new" href="http://dotnetjunkies.com/WebLog/sdhebert/archive/2004/08/19/22582.aspx">http://dotnetjunkies.com/WebLog/sdhebert/archive/2004/08/19/22582.aspx</a>

# re: Not too lazy my friend.

Friday, August 20, 2004 2:04 AM by Shawn Oster    
Over in the Delphi oodesign group I just asked a question around this type of issue. A common approach taken in OPFs (Repositories) is to use a proxy object. To load only the minimum you need for say UI display and put off loading everything until you really need it. Almost like lazy properties except on a need basis instead of a per property basis. You have a 'light' fetch and a 'full' fetch, not a fetch for every single property.

Someone there suggested an IsProxy property. Setting it to True means when you pass it into the repository it only loads the light version, when you switch IsProxy to False it loads the entire thing.

Post a Comment

 
 
Prove you're not a spammer: 
4 + 4 =