Any guidance is most appreciated.
Any guidance is most appreciated? I doubt that, since you hastily dismissed
my previous advice about placing data validation, RI constraints, and
business rules "in the database" behind triggers.
I believe that what I'm suggesting is very sound advice. Moreover, what you
seem to be insisting on in placing that type of processing in PHP, is poor
architecture.
Anyone having a connection to your database can bypass your "business
logic". You may be enthralled with PHP right now, but there may come a time
in the near future when something comes along, say single-page
applications, or responsive UI design, or whatever innovation which
improves the user experience which PHP is not well suited for. You may
change your mind about PHP. But your business logic should nevertheless
remain intact.
Here's a link to an RPG sample which handles data validation, which is
evoked by a before-insert / update trigger.
http://code.midrange.com/ee85fb606a.html
I don't understand your perceptions about RPG being "archaic". But since
you are so predisposed, allow me to point out a few elements which show the
elegance of the design.
The source module compiles into a "service program" which exposes three
procedures namely:
init();
process();
term();
init() and term() procedures "initialize" the module when first loaded into
memory by a piece of plumbing known as a "mediator", and "clean up" after
the mediator notices the module no longer being used (a period of
inactivity).
The process() procedure implements "data validation" and generating a
surrogate key for a record, prior to "insert".
Since RPG runs in the same address space as the database, and has direct
access to records, it can simply call a a procedure to "retrieve" error
messages or completion messages, and return them to "callers", using a
single statement. Notice msgGetText() - retrieve a formatted message from
a DB table and trgMsgAdd() - add a message to an array.
Invalid data prevents the update from occurring, no matter who the caller
might be, regardless of whether PHP is the middleware du jour, or not.
This interface can also be configured to work asynchronously. Say rather
than "validations" process() is used to compose and send email, generate an
order for a bank card and a PIN. Is there any reason to tie up the UI while
waiting for such back-end processing to occur? If you want to provide your
users with the best user experience possible ...
midrange.com
