Re: Mapping SQL Result Sets to Browsers

When it comes to a discussion of business object layers, that's a bit outside my field of play; perhaps a bit out of my league. I'm working in the native virtual machine, and using a procedural language. It's fine with me if the discussion goes in that direction, but I may not be able to add much.

My primary interest is to simplify the interface between SQL result sets and client devices (browsers, for now) through higher level abstractions; to come up with something productive for RPG developers.

Nathan.




----- Original Message ----
From: Aaron Bartell <aaronbartell@xxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Wednesday, July 2, 2008 3:29:13 PM
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers

It's the really messy 20-way joins with subselects and group-bys w/havings

where I'll skip the business layer.

IMO, something this is the most necessary reason for business objects as it
can hide the complexity of producing a result set and instead just requires
the caller know which parms to pass in.

To go back to Nathan's questions, I think RPG holds a special place in my
heart where I allow direct DB access right from the "controller" program
simply because we don't have (don't need) an ORM (Object Relational
Management) layer for most DB access as it is built into the language. On
the flip side I *always* have DAO (Data Access Objects) serve up
"Collections" when I am doing DB access.

Aaron Bartell
http://mowyourlawn.com

On Wed, Jul 2, 2008 at 3:50 PM, Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx>
wrote:

My take is that you're saying there should be a business
objects layer in between? If so, is that to say that the business
objects render as HTML?

Yes, I'm saying there should be a layer in the middle. It's not the
business objects layer's job to know how to generate html, but rather
the web layer's job to know how to generate html based on the business
objects.

The purist in me says there should _always_ be a business object in the
middle. However, the realist in me recognizes that when you're
generating sql on the fly, or even just writing complex sql for
_reporting_ then maybe you'd bypass the business objects. But I will
draw a hard line where reporting means a one-shot, no update, pass at
the db. Truly a report. And even then most reports can be handled
w/business objects. It's the really messy 20-way joins with subselects
and group-bys w/havings where I'll skip the business layer.

-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.)