RE: Encapsulating file access in Service Programs

You are correct.  I tried very unsuccessfully to split them apart.

-----Original Message-----
From: Joel Cochran [mailto:jrc@xxxxxxxxxx] 
Sent: Thursday, September 09, 2004 9:08 AM
To: RPGNext Discussion and Information
Subject: RE: [RPGNext] Encapsulating file access in Service Programs


On Thu, 2004-09-09 at 15:22, Richard Rothe wrote:
> I like the getter/setter thinking.....But I can see the module quickly

> becoming very large.  I believe what I will do is create separate 
> source and /copy members for getters and setters to keep them 
> organized.  Then, another for doing the actual file access and the 
> modules will then be bound together into a service program.

I think you really would want to keep them together: the getters and
setters need to be in the same module that has the file defined in it...
breaking them apart will require you to duplicate fetching or have some
kind of a DS passing requirement between the modules.  Otherwise, how
would the getters and setters have access to the file variables that
will be used in the first module?

Joel
http://www.rpgnext.com

> 
> 
> -----Original Message-----
> From: Joel Cochran [mailto:jrc@xxxxxxxxxx]
> Sent: Thursday, September 09, 2004 5:30 AM
> To: RPGNext Discussion and Information
> Subject: RE: [RPGNext] 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
> 
> 
> _______________________________________________
> This is the RPGNext Discussion and Information (RPGNext) mailing list 
> To post a message email: RPGNext@xxxxxxxxxxxx To subscribe, 
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpgnext
> or email: RPGNext-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives at 
> http://archive.midrange.com/rpgnext.
> 
> _______________________________________________
> This is the RPGNext Discussion and Information (RPGNext) mailing list 
> To post a message email: RPGNext@xxxxxxxxxxxx To subscribe, 
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpgnext
> or email: RPGNext-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives at 
> http://archive.midrange.com/rpgnext.

_______________________________________________
This is the RPGNext Discussion and Information (RPGNext) mailing list To
post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpgnext
or email: RPGNext-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpgnext.