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


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: Wednesday, July 02, 2008 4:41 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers

Walden,

Thanks for the reply. Regarding mixing two layers that "should never be

mixed", are you opposed to reading an SQL cursor and writing it directly

to the screen? 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?

Nathan M. Andelin


On Wed, Jul 2, 2008 at 1:18 PM, Walden H. Leverich wrote:

Say the application is simple as prompting the user to enter a name.
Then generating a list of people having that name (or name prefix)
from

your database.

You're mixing two layers that should never be mixed! With the
exception
of complex reporting where you're building SQL on the fly, I would
have
a business objects layer in the middle. Since you asked how we do it
in
other technologies... In .NET we'd:

string firstName = "bob"; //Get it however

Customer example = Customer.NewCustomer();
example.FirstName = firstName;
List<Customer> customers = Customer.GetByExample(example);

At this point I have a list of customers OBECTS whose firstName is
Bob.
Of course you need to have a mature object infrastructure in place,
but
that's what you should be aiming for anyway.

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

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.