× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



JavaBeans? I thought so. Suitable for RPG? Don't think so.

My personal dislike of EJB is database access, which is the main issue on an 
AS/400.

If a file has 50 or more fields i have to write 50 or more get-methods to 
retrieve one single piece of data, whether or nor it is derived data 
(calculations) and 50 or more setters to update a single piece of data, before 
the record will be updated. I am too lazy to write such nonsense.
I know in the *SRVPGM the fields of a PF are global, so any procedure (read, 
set, get) has access to all data of a read record with only checking the key 
value(s). But what do you achieve with that? Not much, I think. The given 
example looks ridiculous. 

I prefer one read of the record and all data available. Data can be passed in a 
DS (or with a pointer). If you like you can format the required values in the 
*SRVPGM and pass it back in the DS.

The last point on erroneous changing data in the wrong field. PF fields not 
reverenced ina PGM are not accessable (at least that is my experience when in 
DBG, I expect that to be normal behaviour), so putting wrong data in fields is 
a progamming error, not a logical one. 

Each his/her own preferences, but EJBs (and their clones) are (imho) not 
suitable for database access and maintenance.

Just my 2 Euro cents.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 2-2-05 at 13:05 Paul Morgan wrote:

>Rob,
>
>This is the way it's done with Java Beans.
 <SNIP>
>I'm trying to apply these principles to ILE & RPGIV.  You never access the
>data directly but do so through getters and setters.  Getters can do more
>than just return a field value.  The returned value might not even be a data
>field but could be derived from some other fields.  GetName( SSN ) could
>return a formatted string derived from other fields.  It might actually be
>stored in the record as first name, last name and middle initial.  As an end
>developer I don't want to know the details about how the name is stored.  I
>just want to use the name.
>
>If the fields aren't in the program you can't mess with them.  Having the
>entire record's fields in the application program opens you up to all sorts
>of errors.  You could change other fields in the record by mistake.  Using
>getters and setters avoids those types of errors.
<PRUNED>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.