Re: Mapping SQL Result Sets to Browsers

[Nathan Andelin <nandelin@xxxxxxxxx>]

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