RE: Encapsulating file access in Service Programs

On Thu, 2004-09-09 at 13:34, Richard Rothe wrote:
> Regarding file update procedures..... (using native RPG file access, not
> SQL)
> 
> Is the preferred method to create setter procedures for every field in
> the file and have the calling program call each setter to the desired
> value prior to calling the update procesure to update the record ?  Or,
> should update procedures have a parm which is a data structure of the
> record format for the caller to update and then call the update
> procedure ?  

In my opinion, definitely use the setter functions.  And you only need
to have setter functions for fields that other programs are allowed to
update... I do not have setter functions for the userID and timestamp of
the last change to the record: I want the x_update() procedure to do
this automatically.  I emulate auto-increment for unique ids for a lot
of my files, so again I don't want a programmer setting those, I want
the x_write() procedure to hanldle this by itself.  Basically, you
determine what is available to other programs.

The way I use encapsualtion, (a friend of mine calls this approach
"RPGBeans"), you get the record, set the appropriate fields, then
update.  Not unlike what you would do in direct file access.  If you
pass a DS, then you are adding an unnecessary layer to the process. 
That being said, if you really wanted to do this, then add a
"setFileDS()" procedure, but there may be an issue if the DS in the
service program and the DS in the calling program are not the same.  By
that token, you could also have a "getFileDS()" procedure.

Remember that one of the goals here is to have only one object to
recompile in case of a file change.  By default, I'll have to recompile
my service program if I add a new field (using native I/O), but because
I'm using setters and getters I do not have to recompile the calling
program.  If I'm passing a DS though, the calling programs DS should
match the service programs DS, and so you may run into the scenario
where you are right back to compiling both, which is undesirable.

There is a lot of flexibility here.  It does require some work up-front
(which I'm writing a tool to help alleviate), but I think the long term
benefits are worth while.

Joel
http://www.rpgnext.com