Hi There,
I found the Lazy Load feature very interesting especially when implementing properties like Articles Body, but i've found that in all Articles SP's : GetArticleByID, GetArticles,GetArticlesByCategory the Body column is always returned from the DataBase forcing that in every listing of articles(we don't need the body field here) the body is always returned from the DB. Why are we doing that if we have a specific SP (GetArticleBody) that only returns the body of the article or is the LazyLoad feature only to be used in the Object Model Level. The Question is : If we're always bringing the Article Body from the BD, why not always fill the object !
Tks for any reply
Best Regards
PedroBernardo
http://www.inbox.pt

Ok, I will put this in other words.
Can anyone tell me what are the advantages of the Lazy Load method ?
:)
PB

I'm no expert but I think you are right in that the particular field is only meant to be loaded when it is needed and not when the rest of its entity object is loaded, this might be the case where you are requesting more information about an item.

But in this case with reference to the Article class, as you say the Body is being loaded anyway and there doesn't appear to be a reason why body is also set for a lazy load. I think it was probably an oversight in the book, the same functionality is used elsewhere and appears to make sense. Such as in the BLL.Polls with Option.GetOptions(this.ID);


Steve

Lazy load is covered pretty well in the book. The idea is to load data only when it's needed. And then save in memory it in case it's needed again.

Eric

I understand the theory of lazy loading the data only when it is needed. But as pbernardo01 pointed out all of the stored procedures used to get articles include the body field in the select statement. Doesn't this defeat the Lazy Loading implemented in the BLL since the body is retrieved from the database for every article each time they are retrieved? Is this just an oversight in the book or is there something I am missing?

Thanks,
Ben

There are some opportunities for improvement in the data model for this site. Marco did a great job within the time constraints he had, but if people take enough time to analyze all of the data flow and caching it should be easy to see where improvements can be made.

A tuning of the data model is very important when you implement AJAX. AJAX requires a lot of quick responses and you can't afford to hit the DB needlessly, or to return too much data.

Eric

well thank goodness someone else has seen this as an issue. i came across this in my own work nand have still to find a 'nice' way around it. i'm currently thinking i mightload 'null' or similar from the db when particular fields are not required - it simply doesn't make sense to populate whole objects when only certain fields are required.

Be careful - you need to distinguish between a data value of null, or a value that has not been read yet. I'd probably break the entity classes up into separate classes, and you use the one you need. All fields of that smaller class would be populated. You may need a lot of entity classes.

Or maybe look into the upcoming Entity Framework:
http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

Eric