I’m not sure whether lazy load pattern is useful here

Question

Hello,

I’m currently reading a book on website programming and author mentions that he will code DLL objects to use lazy load pattern. I think that conceptually I somewhat understand lazy load pattern, but I’m not sure if I understand its usefulness in the way author implemented it

BTW - Here I’m not asking for usefulness of lazy load patterns in general, but whether it is useful in the way this particular book implements it:

1) Anyways, when DLL object is created, a DB query is performed (via DAL), which retrieves data from various columns and with it populates the properties of our DLL object. Since one of the fields ( call it "L" ) may contain quite a substantial amount of text, author decided to retrieve that field only when that property is read for the first time.

A) In our situation, what exactly did we gain by applying lazy load pattern? Just less of memory usage?

B) But on the other hand, doesn’t the way author implemented lazy load pattern cause for CPU to do more work and thus longer time to complete, since if L is retrieved separately from other fields, then that will require of our application to make an additional call to Sql Server in order to retrieve "L", while without lazy load pattern only one call to Sql Server would be needed, since we would get all the fields at once?!

BTW – I realize that lazy load pattern may be extremely beneficial in situations where retrieving particular piece of data would require heavy computing, but that’s not the case in the above example

thanx

Answer 1

It makes sense if the DLL objects can be used without the L field (most of the time). If that is the case your program can work with the available data while waiting for L to load. If L is always needed then the pattern just increases complexity. I do not think it will significantly slow things down especially if loading L takes more time than anything else. But that is just a guess. Write both with lazy loading and without then see which is better.

Answer 2

Hi,

I think that this is pretty useful when applied to the corret columns. For instance lets say that you have a table in your database, Customers, and inside that table you have a column named CustomerPublicProfile, which is a text column which can be pretty big. If you have a screen (lets call it Customers.aspx) which displays a list of the customers (but not the CustomerPublicProfile column) then you should try and avoid populating that column. For instance if your Customers.aspx page showed 50 customers at a time you shouldn't have to get the CustomerPublicProfilecolumn for each customer. If the user decides to drill down into a specific customer then you would go and get the CustomerPublicProfile column.

About B, yes this does make N extra calls, where N is the number of customers that the user decided to drill down into. But the advantage is that you saved a lot of extra un-needed overhead in skipping the column in the first place. Specifically you avoided getting M-N values of the CustomerPublicProfile column, where M is the number of customers that were reterived on the Customers.aspx page to begin with. If in your scenario M has a value close to N then it is not worth it. But in the situation I decribed M is usually much larger than N so it makes sense.

Answer 3

I had a situation like this recently where I was storing large binary objects in the database. I certainly didn't want these loading into the DLL object every time it was initialised, especially when the object was part of a collection. So there are cases when lazy loading a field would make sense. However, I don't think there is any general rule you can follow - you know your data and how it will be accessed. If you think it's more efficient to make one trip to the database and use a little more memory, then that is what you should do.