Re: MVC in RPG?

["Joel Cochran" <joelcochran@xxxxxxxxx>]

On 10/2/07, albartell <albartell@xxxxxxxxx> wrote:
> > 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.
>
> In the same breath we have to count the hours we saved NOT having to write
> DB I/O code, and measure it against the time spent having to check all
> references to a column that are "hard linked" in code.


Yes, but you only invest that time once, and with a little Code Generation
assistance this can be made largely trivial (hence the RPGBeans.com project
in the first place).  Contrast that to making an application wide change,
which could be substantial, only to find out a week later the boss wants
another one so you do it all over again.

I'm not saying it's easy: as I've stated several times recently, it takes
lots of discipline.  What I am saying is that I think it ultimately proves
worthwhile.

As for the rest of your post, you are trying to guard against projects where
> you don't have time to plan for all current business logic and instead
> default to putting a veneer over DB2 to protect your data.  The more we
> collaborate the more I think you want veneers not for DB I/O but instead
> for
> business logic changes.  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.


In OOP, you could actually do both if the situation demands it.  The layer
of business rules could rely on the DB layer to retrieve data, which may
actually use Stored Procedures to access the multiple files.  This approach
would definitely allow you to distinguish between the Database Structure and
the Object Structure which do NOT have to be the same.  Having the Service
Program mirror the Database layout is just typically the first step for
procedural programmers to apply and embrace Encapsulation.  Once you realize
the two are not necessarily tied together the sky's the limit.

I agree that it is the data encapsulation/protection that intrigues me most,
not necessarily outsourcing the DB access.  Proper layering will also allow
the same business rules to be applied across different UIs.  A CGI program,
a DSPF, or even a WebService could all rely on the same code to protect the
integrity of the Database.