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

The benefit of having all validity checking in one place seems like a big
win to me, especially when one begins to deal with data updates from places
other than the green screen.
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: RPG programming on the AS400 / iSeries
Date: 11/14/03 15:13:09
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