that we use /Model/-/View/-/Controller/ (/MVC/) to work with our data?
We divide our code according to MVC. But DB I/O modules (the model) could
be further subdivided - where data validation and RI constraints are moved
to Triggers, while leaving code in model and view modules to issue DB I/O
and UI I/O statements.
Returning to the thought which Buck expressed about Triggers being just
another API interface provided by IBM... You might view all database
operations whether implemented via RLA or SQL as APIs, evoked by
applications.
One problem with IBM's external Trigger implementation is that the calls to
Triggers only passes 2 parameters. Applications and Triggers may need other
ways of communicating with one another.
One way of communicating between ILE applications and Triggers is the use
of service program exports bound by both. I've just been experimenting with
a data export as follows:
d rdtrgjob e ds extname(rdtrgjob) qualified
d rdtrgevt e ds extname(rdtrgevt) qualified
d rdtrgmsg e ds extname(rdtrgmsg) qualified
d before e ds extname(myfile) qualified
d after e es extname(myfile) qualified
d trg ds export qualified
d job likeds(rdtrgjob)
d evt likeds(rdtrgevt)
d msg likeds(rdtrgmsg)
d bef likeds(before)
d aft likeds(after)
d esc n
The exported "trg" data structure is actually a complex data structure
which includes information about the job, the Trigger event, message data,
before and after record images, etc. shared between application and Trigger
call stack entries.
So, at least with ILE interfaces, application modules and Triggers are not
limited to the 2 parameters provided by IBM. And I'm pleased with the
compactness of the RPG code.
Nathan.
midrange.com
