RE: MVC in RPG?

["albartell" <albartell@xxxxxxxxx>]

Have you gotten into the stage of needing to do file maintenance to see if
there is fruit to your labor?

Do you have an example you can show us?

I can see how code generators would definitely help the process, as long as
what they create is manageable. 

> 3. Each field has a getter that returns it's data.
Have you done performance comparisons to see if there is any additional
overhead with having so many API calls?

Thanks,
Aaron Bartell
http://mowyourlawn.com


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of chris beck
Sent: Friday, September 28, 2007 9:07 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: MVC in RPG?

I believe that we have come up with a solid implementation of a Service
program DB abstraction layer in RPG. We have been creating a fairly large
new CGI app (over 100 files) from scratch for the past year and decied to
create a DB abstraction layer for the entire app. When it was proposed, I
thought it was a crazy idea. I thougt all we would be doing was createing
DAO's but this is not true. I created a tool that builds a module for each
file. We then only have to manually create a routine if we want to get the
data in a strange new way, but then I would have had to do it anyway with
tradional code and in every program that I wanted to use it. This way I only
ever have to code it once and it is hidden. This has saved us 10's of
thousands of lines of code. 
 
Some other benefits: 
I never have to wory obout coding a F spec, I just prototype in the file or
the service program and access the field I want.
I don't have about chains, setll reade or record locking, It just all
happens under the covers. 
We don't need to create an index before writing a program, since all access
is through SQL we just periodically check the index advisor and let it
create what it needs. 
 
I don't think I will ever write another RPG app without a DB abstraction
layer. 
 
Answeres to Aaron's questions:
1. All files get one.
2. We return a indicator on a record load call, or on any other call we set
the SQL CPF Message and use another method (subprocedure) to retrieve it. 
3. Each field has a getter that returns it's data.
4. opOrderbyCust(CustId);
    dow getNextCustOrder();
      // Process the records here.
    endDo;
5. We never lock a record. The DAO automaticaly checks for record changes on
a update.
6. stCustOrderDesc('this is the order');
    insertCustOrder(Custid:OrderId);
    
If I only need to get one record I would just call the routine for whatever
field I need. For example gtCustOrderDesc(CustId:OrderId);
 
Chris Beck