Why would you want to do this if you have SQL?
I'm not sure I understand the question. Are you asking about externalizing
I/O into service programs? Or are you asking about SQL vs. RLA?
Regarding externalizing I/O into service programs, that's good
architecture. It appropriately separates logic (i.e. DB I/O separate from
UI I/O, etc.). That's a tenet of the model-view-controller design pattern,
which improves code readability, maintainability, and adaptability to
technological change.
By DB I/O logic, I'm referring to consistent error handling with
appropriate (friendly) end-user messages, implementing a policy for
optimistic locking with appropriate and consistent message handling,
consistent and appropriate handling of data validation,
referential-integrity constraints, and business rules applicable to DB I/O
operations.
If you're asking about SQL vs. RLA, my position is that there are valid use
cases for both. RPG op codes are better suited for RLA operations, while
SQL is better suited for set-based operations (filtered queries, etc.).
That is the whole purpose of SQL. To build a logical view of data ...
By "whole purpose", surely you don't mean "only purpose" of SQL.
Technically, one can use DDS logical files, including joins to implement
logical views. But I create SQL views in most cases.
What would you gain by having to do everything manually when SQL does it
all for you?
I'm not sure I understand what you mean by doing "everything manually". Are
you referring to the automation provided by the SQE? I say use it when the
use-case calls for it. Surely, you're not suggesting that the SQE adds
value to RLA use cases. No, it just adds unnecessary overhead in that case.
midrange.com
