RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

In my opinion, it's fairly pointless having all i/o for one "file" in a
single component. That doesn't actually do much to separate the physical
implementation of the database from the business logic. 

What I do believe in however is having all i/o for one "business entity"
in one place. The data could be in one file or twelve... the client
program doesn't need to know or care. It just calls a procedure to get/set
some business data... The procedure is the only thing that needs to know
what files/fields that data lives in. 

Stu

-----Original Message-----
From: Rich Duzenbury [mailto:rduz-midrange@xxxxxxxxxxxxxxxxxxx] 
Sent: Friday 14 November 2003 21:00
To: RPG programming on the AS400 / iSeries
Subject: RE: ALL I/O in single module was(ARGH!!! (was file open with LR))



>   This, by
>the way, is another reason that I advocate moving ALL file I/O for a
>file into a single module; it avoids some of these issues.  It sometimes
>causes a little extra upfront work, but in the end it makes your life a
>lot cleaner.

I've been coding RPG since '84, so I'm somewhat of a dinosaur in this
regard.

I haven't been convinced (yet!) that it's better to have the file I/O in 
one module.  With the existing code, I can look at the F specs and see
what 
gets read and/or updated.  I can scan for CALL and see any programs that 
might also update a file.

With procedures, the code is much more intertwined, and it doesn't seem as

easy to be sure what a particular program might be doing to the database.

Some opinions are that this makes for easier maintenance.  In the case of 
RPG, I've seen approaches of this type where the record layout is pulled 
into the main program via an external data structure.  The procedure then 
reads the record from the database, loads it into the data structure, and 
then returns the data structure to the main program.  This doesn't appear 
better than just having the file defined in the main program, as any
change 
to the underlying table will surely require a recompile of both the main 
program and the procedure in the event that fields are added to the table 
or changed.

I'm trying to think of other systems where using a function to do the I/O 
and passing back a data structure is done.  I can't think of any.  For 
example, when I write Perl code to access a MySQL database, I generally do

it as simply as possible:

my $dbh = connect();

# Get last name, first name from the table
my $sth = $dbh->prepare( "SELECT ulnam, ufnam FROM person") ;

$sth->execute;

while ($row = $sth->fetchrow_hashref) {
     # do stuff with each row
}

I don't try to write a function that returns a data structure for each 
record, although I suppose I could.  The reason I write it this way is 
because it's clear and concise.  I could build this as a routine that 
forces the user to implement a call-back to get back each row.  I could 
somehow use a static variable or parameter to indicate whether the query 
should be run, and then return each row on successive calls to the 
function.  I don't see how that's easier or better.

I don't try to write an object that returns a data structure for each 
record, although I suppose I could. I could have an object with a method 
for setting the desired database key.  I could have another method for 
executing the query.  And another for returning each row.  But why?  It's 
building a new interface that's not necessary.  There is already a direct 
interface to the database.  Why recreate it?  Anyone familiar with the 
database can already retrieve any data in it.  If you force someone to 
learn your object-ified way of accessing the data, it seems to me you are 
getting in the way of getting the job done.

If I have this code in 100 different programs, and it has to change, I 
think that's probably OK.  The reason is - if you have to change the query

to return a new field, say for example, the person's middle initial, I
also 
have to change all of the callers to actually *do something* with that new

element.

I'm not trying to rain on your parade, I am just interested in 
understanding what the rationale is.

Regards,
Rich

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



If you are not the intended recipient, please notify the sender by return email 
and then delete the message from your computer. The Skandia UK Group reserves 
the right to monitor e-mail communications through its networks.

No contract may be concluded on behalf of the Skandia UK Group by email.

Skandia Life Assurance (Holdings) Limited Skandia Life Assurance Company 
Limited Skandia MultiFUNDS Limited, Skandia Investment Management Limited.

Registered Nos: 1606702, 1363932, 1680071, 4227837, England
Registered Office: Skandia House, Portland Terrace, Southampton SO14
7EJ, United Kingdom

Royal Skandia Life Assurance Limited Registered No : 24916 Isle of Man
Registered Office: Skandia House, King Edward Road, Onchan, Isle of Man IM99 
1NU, British Isles

Skandia Life Assurance Company Limited, Skandia MultiFUNDS Limited, Skandia 
Investment Management Limited and Royal Skandia Life Assurance Limited are 
authorised and regulated by the Financial Services Authority for UK
investment business.

Internet: www.skandia.co.uk