RE: Separation of Presentation, BL, and I/O Tiers

I'll check out the article and would love to see examples.

When you say mediator, do you mean something like converting the application
over from one that uses a entire externally defined record to one that uses
only the data it really needs, through a GetCustName() and GetCustCity()
kind of procedure, for example?  Then, the procedures would be the only ones
actually using the I/O modules?

I've implemented this in a few file-specific service programs where the
actual I/O module is a local procedure in the service program and the
exported procedures use it, but haven't gotten real far with that method
yet.  The lack of generic-ness has been somewhat of a stumbling block.
Isn't this what the Get and Set methods in OO programs are all about?  I
think I've read they do a Get/Set pair for every field in a file.

> -----Original Message-----
> From: David Morris [SMTP:David.Morris@plumcreek.com]
> Sent: Wednesday, April 10, 2002 1:18 PM
> To:   rpg400-l@midrange.com
> Subject:      RE: Separation of Presentation, BL, and I/O Tiers
>
> Mark & Nelson,
>
> I prefer to have a Mediator in the middle. This lets you decouple the
> I/O routines from the application. That way you don't tie yourself to
> a specific implementation. There are some tricks you can use to
> do this with native based I/O, but SQL is much simpler. I have done
> it both ways and would recommend starting with SQL as you have
> and then working toward native (because it can be much faster).
>
> With a Mediator in the middle you can defer the actual coding of
> a native interface. I wrote an article about this a few years ago that
>
> is still available online at:
>
> http://www.mcpressonline.com/mc/.214a309b
>
> As I said I have done this quite a few times and used various
> techniques. Unfortunately, most of that work is not my property,
> but I do have a pretty good base that is. If you are interested, I
> would love to put out a base as part of the iSeries-toolkit at
> www.iseries-toolkit.org and collaborate on this in a free and open
> source version.
>
> I have taken this to the level where edits can be attached to
> fields at any time and native file I/O can be used like SQL.
> This is hard to explain, but a database I/O wrapper wraps
> access and provides trigger support. That way all access
> including things like DBU and SQL get this Mediated support.
> RPG is not the best language for this, but it does work. I used
> a cache to support the dynamic calls that are required, which
> really helps to reduce the overhead of this type of I/O server.
> The biggest problem with RPG is the limited multi-threading
> awareness.
>
> David Morris
>
>
> >>> MWalter@hanoverwire.com 04/10/02 10:36AM >>>
>
> Nelson,
>
> I just yesterday got an I/O service program to work that way. I define
> an
> externally descibed MODS in the calling program that is based on a
> pointer.
> Then the subprocedure in the service program also defines an
> externally
> descibed mods that is based on a pointer. I issue a select count(*)
> into
> :count and allocate the memory for the MODS based on the count. Then I
> fetch the records into the MODS and return the pointer as well as the
> record count. I'll gladly send you the source for my little test
> program
> privately if you wish.
>
>
> Mark
>
>
> Mark Walter
> Sr. Programmer/Analyst
> Hanover Wire Cloth a div of CCX, Inc.
> mwalter@hanoverwire.com
> http://www.hanoverwire.com
> 717.637.3795 Ext.3040
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************