RE: MVC in RPG? -- RPG400-L

Totally agreed.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell
Sent: Tuesday, October 02, 2007 3:33 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: MVC in RPG?

<clip>
And if that is the case I think a better approach would be to develop
based on function vs. tables. For instance, instead of coding all of
the DB I/O for the 5 files it takes to calculate a price you could
instead code two procedures named Price_getWholesale and
Price_getRetail.
</clip>

HTH,
Aaron Bartell
http://mowyourlawn.com

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Joel Cochran
Sent: Tuesday, October 02, 2007 3:13 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: MVC in RPG?

On 10/2/07, Lim Hock-Chai <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:

3. If you still have to do research on all programs that uses the DB
layer when changing attribute of a field, you are really not gain much

from it. As far as adding new field, it is only true if your DB layer

does not have procedure that allowed caller to get the entire DS of
the file. Unfortunately, getting the entire DS is a pretty useful
function to have.

OK, let's look at this another way. Using "Classic I/O", you would have
to find all the code that references the field anyway, so you aren't
losing anything there.

With the database layer, you have the option of updating the consuming
code, but it isn't required: you could leave the original procedure
intact, so that preexisting code continues to function, and add a new
procedure for the updated length of the field. You could even change
the code of the original procedure to call the new one behind the
scenes, making whatever adjustments are necessary to make the two
compatible.

If you need to add data integrity checking, you only add it ONE TIME to
the database layer. Let's say the business rules for a field change,
whether the field definition changes or not: in option A, implementing
that business rule requires you to find every instance in your code that
references that field, updating the behavior, and then recompiling all
the *MODULES, and updating or recompiling all the programs. In option
B, using a database access layer requires changes to only one code
source: it gets compiled, and an UPDSRVPGM command is issued.

From a maintenance standpoint, I like option B a lot better. And
honestly,

how often are you changing the attributes of existing fields?

As for the DS issue, I'm not sure I follow: retrieving the DS from the
Service Program would simply return whatever the current definition is.
If your code does not consume new fields, then what is the issue?

4. There are several ways to go around the problem, the point being

that are you really gaining anything from DB layer? Why replace RPG
io functions that all RPG developers are familiar with with your own
io functions that no new comer can understand without additional

trainings?

The functions are no more difficult than any other call to any other ILE
procedure. And you aren't REplacing the IO functions, you are
DISplacing them. I wouldn't hire a programmer who couldn't grasp this
quickly. If anything, you are making their job easier because they only
need to knwothe interface, not the entire database. It is definitely
not rocket science.

--
Joel Cochran
http://www.developingfor.net
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.