Comments on: There’s Lazy Loading, And Then There’s Lazy Coding http://davybrion.com/blog/2009/11/theres-lazy-loading-and-then-theres-lazy-coding/ Trying to walk that thin line between intelligence and ignorance Thu, 29 Jul 2010 21:01:23 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Biswanath http://davybrion.com/blog/2009/11/theres-lazy-loading-and-then-theres-lazy-coding/comment-page-1/#comment-23025 Biswanath Mon, 23 Nov 2009 06:30:25 +0000 http://davybrion.com/blog/?p=1905#comment-23025 Totally true. We were working with some hierarchical data and we started with eager loading for all the levels. As it turned out most of the cases we did not needed all the data we were loading. Then we changed everything to the lazy load, but as it turns out sometimes we were firing two many queries for the some of the lower level of hierarchies. Then finally we have to go for a combination of lazy with eager as you have mentioned to hit the sweet spot. Totally true.

We were working with some hierarchical data and we started with eager loading for all the levels. As it turned out most of the cases we did not needed all the data we were loading.

Then we changed everything to the lazy load, but as it turns out sometimes we were firing two many queries for the some of the lower level of hierarchies.

Then finally we have to go for a combination of lazy with eager as you have mentioned to hit the sweet spot.

]]> By: Al Tenhundfeld http://davybrion.com/blog/2009/11/theres-lazy-loading-and-then-theres-lazy-coding/comment-page-1/#comment-22990 Al Tenhundfeld Thu, 19 Nov 2009 16:45:04 +0000 http://davybrion.com/blog/?p=1905#comment-22990 If you need data, then it is your responsibility to retrieve that data <strike>as efficiently as you can</strike> as efficiently as performance requirements dictate. Otherwise, yes, lazy loading is a useful pattern, but like any pattern, it can be abused easily. If you need data, then it is your responsibility to retrieve that data as efficiently as you can as efficiently as performance requirements dictate.

Otherwise, yes, lazy loading is a useful pattern, but like any pattern, it can be abused easily.

]]> By: Anders Ivner http://davybrion.com/blog/2009/11/theres-lazy-loading-and-then-theres-lazy-coding/comment-page-1/#comment-22989 Anders Ivner Thu, 19 Nov 2009 13:26:11 +0000 http://davybrion.com/blog/?p=1905#comment-22989 I agree that lazy loading is not the problem, and that a lot of the perceived problem is caused by developers relying too much on it, either out of laziness (though one could argue a YAGNI or "optimize later" stance - leading to "death by a thousand cuts") or ignorance. But I think the root problem is that contextual span fetching is inherently a DRY violation, meaning that load spans and domain logic are defined separately, thus making them hard to maintain in sync as an application evolves. I am thinking here of a load span being defined in the context of e.g. a particular service method. The domain logic would obviously go on the domain model classes, which we want to keep independent of any persistence concerns. When we make a change to a method on a domain class, requiring some new data, we need to understand which spans (there could be more than one) are affected and amend them as appropriate. In the end, the only cure is measuring performance and profiling, which is something one should do anyway. Cheers! /Anders I agree that lazy loading is not the problem, and that a lot of the perceived problem is caused by developers relying too much on it, either out of laziness (though one could argue a YAGNI or “optimize later” stance – leading to “death by a thousand cuts”) or ignorance.

But I think the root problem is that contextual span fetching is inherently a DRY violation, meaning that load spans and domain logic are defined separately, thus making them hard to maintain in sync as an application evolves.

I am thinking here of a load span being defined in the context of e.g. a particular service method. The domain logic would obviously go on the domain model classes, which we want to keep independent of any persistence concerns. When we make a change to a method on a domain class, requiring some new data, we need to understand which spans (there could be more than one) are affected and amend them as appropriate.

In the end, the only cure is measuring performance and profiling, which is something one should do anyway.

Cheers!

/Anders

]]>