Hmm (just thinking out loud),
In Java, or .net, or most of the other programming environments out there, database access is not tightly coupled to the language. The business languages on System i ARE tightly coupled to the database. In environments where DB access is an extension to the language being used, I can well understand the desire to abstract DB access, especially since the fundamental support for the DB is itself an abstraction.... In RPG and Cobol on System i, which have phenomenal native access to the database, adding DB abstraction seems a bit pointless.... The term "lipstick on a pig" might be appropriate, except that it's not a very flattering image.
It seems to me that we're chasing the dream of "OO-like" application design in RPG. This can be simulated to an extent, but since RPG and Cobol are NOT OO languages, requires a great deal of discipline to implement consistently. IMO, the native supporting opcodes for database access are the simplest way for a developer to obtain their data.
Ultimately, DB access is just part of the nuts-and-bolts that makes up an application. The real heart of the application is the business logic, and this is where we should focus our attention. Contrary to the Kohler commercial, one does not build a house around a plumbing fixture. The plumbing fixture is supposed to support the needs of the home. In much the same fashion, access to the database simply supports the needs of the business logic.
Regards,
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Mike
Sent: Tuesday, October 02, 2007 11:30 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: MVC in RPG?
This is where I differ... lets face it, not many punks my age (27) are doing
RPG development. Heck there are programs older than me on our system right
now. Free-Format and separating I/O logic is a step towards what the Java
and .NET developers are doing today. If they had to jump into an RPG program
because the only RPG programmer just got fired or quit or worse, they would
have a better chance of understanding the subprocedure calls vs. CHAIN,
SETLL, and READE ("what the hell is this?").
Is this a logical step? I really don't know. I know what is easiest for a
RPG programmer, but I am also trying to look into the future of what if.
On 10/2/07, Lim Hock-Chai <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote:
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?
midrange.com
