Re: Mapping SQL Result Sets to Browsers

[Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>]

Walden H. Leverich wrote:
> As for business objects, their appeal (to me at least) is that you can
> embed the business logic into them and not have to worry about it as the
> consumer. Take something "simple" like item balances. How many rubber
> chickens are available for sale? Well, is it the AvailQty bucket? Or is
> it AvailQty-ReservedQty, or perhaps
> AvailQty+InboundQty-ReservedQty-DamagedQty, or some other combination of
> quantities. An item business object could have a property like
> "AvailableForSale" which was the correct computed value, and everyone
> would be singing the same tune. Can this be done w/out business objects?
> Of course. But there's a big (programmer) performance gain in being able
> to write:
>
> Item x = Item.GetItem(12345);
> int qtyForSale = x.AvailableForSale;
>   
I am not, not, NOT, *NOT* going to get into this discussion in any 
long-running way, but I am absolutely compelled to point out one thing 
here: this sort of (programmer) performance gain very easily translates 
into performance LOSS for the user.  In the above situation, let's take 
the calculation.  Is it performed when the Item object is loaded?  Or 
when the property is requested?  In the former case it will be 
calculated and often never used, while in the latter case it will be 
calculated over and over again.  Unless of course the field is 
lazy-loaded, which means adding another boolean field to be compared to 
every time the property is accessed.

Make that a few dozen properties, and then start throwing in data from 
foreign keys.  For example, the item has a class, and the class is an 
object itself with a description.  When does the item class object get 
instantiated?  When the item is loaded?  When the class is accessed?  
When the class description is accessed?  Every time?  Is there an 
instance of the class associated with every item?  Or are the values 
cached?  Who caches them?

Don't get me wrong, I'm not knocking the idea of business objects per 
se.  But *any* time you delegate the access or computation of 
database-derived values, you run the risk of code bloat and performance 
degradation.  Business objects and standard database access both have 
their place, and wholesale replacement of one by the other can be 
dangerous to your application.

Just a view from the bleachers...

Joe