RE: File Encapsulation Quandary

Hi Kurt,

Firstly, wonderful to see that you're moving down a path of abstracting
your data access from your business and application logic. Secondly, great
to see that you're willing to put yourself out there and ask for ideas and
input!

The approach that we take is that we use RLA in our data access "Objects".
These are then peered with our business logic "Objects". There are a
number of rules as to how interactions can occur horizontally and
vertically between these layers. We code generate 90% of our data access
layer and approximately 40% of our business layer (not the logic, but
controlled accessors and modifiers for example). Our files aren't always
"neatly" laid out such that a single table holds the entire information
for an entity - we've tried to perform a reasonable level of normalisation
whilst not causing too many performance issues. So our data access Objects
will often time look to multiple tables - it's not always a one to one
relationship.

This provides us with a scalable model - we have specialists who work on
different tiers of the architecture and it works well for us. But, then
again, we also have a full event model, basic garbage collection etc all
built in house in RPG, so we're (probably) not a typical RPG shop.

Happy to provide additional information if you're interested.

Regards,
Brenden Conolly

From: Kurt Anderson <kurt.anderson@xxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Date: 05/04/2012 05:30 AM
Subject: RE: File Encapsulation Quandary
Sent by: rpg400-l-bounces@xxxxxxxxxxxx

--------------------------------------------------------------------------

Boy, Scott, you really know how to make a guy get defensive. I think it's
because you're making an assumption with the whole item master scenario.
I'm not at all suggesting to not modularize logic such as
item_getInventory(). I'll try to take a step back to analyze why we're
doing what we do and explain it.

First off, we don't encapsulate all of our files. Only the ones that have
business logic directly associated with the file.
For example:
We have a file with records with effective dates associated with them. We
also have some clients who apply grace periods to their effective dates
(that we need to interpret and apply on the fly if a record wasn't found
w/o the grace period). Without this service program, this file would be
used in over a hundred programs. Instead of having every program that
needs to use this file have to go through all the gyrations of looking for
the effective record, it's all handled in the service program. I also
call this service program a business unit. The service program is set
up so all the caller has to do is code the statement "line =
getEffectiveLine( date: otherinfo ); "

But I did take these business unit service programs that revolve around
files a step further. I designed them to fully encapsulate the file in
such a way that the caller could use the file from one location. This was
a carry-over from my last job, where we did use it as means for other
systems to get the data it needed. We weren't a SQL shop, so that was
probably part of the reason for using this method.

I think a big part of trying to keep the file access in one module is
because at my current job we don't have a CMS or a cross-reference
utility. We have a homemade cross-reference utility, and it's mostly ok,
but not 100%. So when it comes time to implement a file change, having
that file in one location has helped quite a bit. I do realize that we
could achieve this same benefit by moving further toward SQL, which we are
slowly doing.

Maybe I should try cutting out all of the Gets and Sets and procedures
that mimic RPG operations (SetLLFile() ReadFile() ChainFile()). I went
looking through our file encapsulated service programs and in every one
there is at least one procedure that will perform all of the necessary
actions to produce the result to a common requirement (vs forcing the
caller to issue each separate procedure call for things such as setll,
reade, get, get, get, etc). However I know there are instances where
programs do use those individual calls - usually for the most basic of
needs.

I have to admit, I really do like the idea of centralizing i/o access,
however I do concede that there is added complexity with wanting all file
access to occur through one location.

-Kurt

This email is sent by Auto & General Insurance Company Ltd, A&G Insurance Services Pty Ltd, Australian Insurance Holdings Pty Ltd or a related body corporate (A&G) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of A&G. This email is confidential and subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised.
If you are not the intended addressee please immediately notify the sender and then delete the email. A&G does not warrant that this email is error or virus free.