RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

Makes a lotta sense ta-me, Joe.

I've never implemented this, but seen it done on JDE and read many of your
posts on subject.  My view is that, contrary to article posted earlier,
there are two points of interface between the user and the data (the
Human-Machine-Interface).  One is when the user enters data, and the other
when the file is updated.  In both cases the data needs validated, but
additional edits are necessary in second phase (because, even if
milliseconds apart, the underlying data will in some cases change, ie last
seat on airline already booked).

So dunno how this view fits in MVC (Model-View-Controller) architecture, but
seems like a trigger could call the user-entered-data-validation
sub-procedure that the online portion would call, and then do additional
edits and such.

I don't believe that state-of-art IA (Information Architecture) is SNAFU,
let alone FUBAR.. just because what's coming out in future is (by
definition) not precisely known, so Can't be recognized with any great
clarity...  Seems like these discussions are useful to draw a bead on "Good
Practices".  ("'Best' is the enemy of the 'good'.")

| -----Original Message-----
| From: rpg400-l-bounces+jt=ee.net@xxxxxxxxxxxx
| [mailto:rpg400-l-bounces+jt=ee.net@xxxxxxxxxxxx]On Behalf Of Joe Pluta
| Sent: Monday, November 17, 2003 11:15 AM



| Personally, I've come to embrace the idea of using both.  Since triggers
| and referential integrity really amount to writing business logic in
| separate places, I prefer to combine all that logic in one I/O module
| around each file (or group of related files), and then exclude all
| access except through that module.
|
| I only make files accessible as necessary, and for those files I do have
| to leave open to the public, I can put a trigger on them.  If the
| trigger senses an attempt to access the file OTHER than through the I/O
| module, it denies the request.
|
| Simple, clean, and all my business rules are in one piece of code.  This
| is the best of both worlds.  This also allows the easy implementation of
| things like row-level security and other features that DB2/400 doesn't
| support natively.