RE: MVC in RPG?

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