Personally I fully advocate their use (and agree with Walden,
disagree with Joe).
It's hard for me to disagree with either. They both make valid points.
Joe was pointing out some trade-offs between exposing a simplified
interface, vs. >degradation in performance. While Walden pointed to a valid
case for using a business object.
There is no degradation in performance when using business objects (used
correctly), in-fact there is an improvement in performance in my experience!
Regards
Maurice
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Nathan Andelin
Sent: 08 July 2008 19:52
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Mapping SQL Result Sets to Browsers
From: Maurice O'Prey
I don't really know what point it is you are making,
but it seems to me you are promoting the use of
business objects.
Yes and No. How's that for a politically correct answer?
A "business object" may mean something quite different to a developer who is
using an OO language within an OO runtime environment, than to one who is
using a procedural language with traditional top-down, left-right, program
flow. Since I generally work in the latter, we may have some difficulty
understanding one another.
Notwithstanding, in the event that certain code or data needs to be shared
and adapted across multiple contexts, then we'll likely agree that it should
be encapsulated and maintained as a separate unit, and expose a common
interface, applicable to every context where the interface is needed.
I don't see Customers, or Orders, or Order Items, or Products, or Users as
"objects". I generally see them as "records", which may be passed in part
(or whole), by value (or reference) to any number of procedures which may be
shared in number of contexts for further processing. The coupling between
data and methods may be loose. I prefer that kind of flexibility. But an
OO programmer may envision tighter coupling between data and methods. And
that may depend a lot on the individual you're discussing with. If an OO
programmer ever advocates something like extending a "person" object to
"employee" or "customer" objects, then I'd probably need to bow out of the
discussion.
Personally I fully advocate their use (and agree with Walden,
disagree with Joe).
It's hard for me to disagree with either. They both make valid points. Joe
was pointing out some trade-offs between exposing a simplified interface,
vs. degradation in performance. While Walden pointed to a valid case for
using a business object.
Nathan.
midrange.com
