Nathan,
#HE EXAMPL
-Walden
--
Sent from my wireless device.
-----Original Message-----
From: Nathan Andelin <nandelin@xxxxxxxxx>
Sent: 07 July, 2008 14:52
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers
Walden,
I have no trouble visualizing SQL result sets on screens in place of 5250 subfiles. And I appreciate your explanation of using a business object to calculate and host calculated values.
An Available Quantity column might also be derived from calculations on an SQL select statement, and generated with a result set, but I understand that at some point SQL may become unwieldy, and people may be better served by encapsulating calculations in a business object.
It's also more clear to me that SQL result sets may not have all the attributes or methods needed to seamlessly interface with a "presentation layer", such as JSP and JSF. So additional code may be written or generated to build collections suitable for consumption by a presentation layer.
I think you mentioned in an earlier message that a presentation layer should know how to present business objects to users. And your code sample evidently outputs order items. But is it professional grade output suitable for business contexts? Or would there be some sort of middleware layer bridging the differences between business objects and presentation objects?
Thanks,
Nathan.
----- Original Message ----
From: Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Monday, July 7, 2008 10:12:54 AM
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers
I don't understand the notion or appeal of result sets and business
objects.
A result set is just a collection of rows. In SQL-land we tend to think
of getting a bunch of rows from the db and then processing them, as
opposed to the RPG read/process/read approach. Neither is wrong or
right, just different. Anywhere there's a subfile the sql people would
think in terms of a result set. Order entry, item search, customer
lookup, etc.
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;
especially when you add in an intelligent IDE with intellisense (or
whatever RDi calls it) which will prompt you with the available options.
Also business obejects let us string together relations w/out having to
worry about how the relations are made, since the linkage is
encapsulated in the business object. For example:
Order o = Order.GetOrder(12345);
List<OrderLine> lines = o.GetLines(); //Here's a result set.
Foreach(OrderLine line in lines)
If(line.Item.AvailableQuantity > line.OrderedQuantity)
Print("Order {0}, Line {1} requested {2} of item {3} ({4}), only
{5} available!",
o.ID, line.ID, line.OrderedQuantity,
line.Item.ID, line.Item.Description,
line.Item.AvailableQuantity
);
In that example I walked from Order to the list of order lines, to the
items on each order w/out having to know a darn thing about how the
database was structured.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
midrange.com
