Re: Mapping SQL Result Sets to Browsers

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