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.