I can't come up with a problem that their solution solves. Can you
provide any examples?
Do you view file level checks as a problem? Would you rather have
individual files referenced in just one service program, or many? The
redbook posed a case where a DB normalization exercise split a file into
two. A procedure interface may provide a single logical view of two
separate files. A change in a file layout doesn't necessarily require a
change in a procedure interface.
However, for me the compelling reason to separate DB I/O into service
programs is for the sake of application architecture (readability,
maintainability, adaptability, and cohesiveness). A common objective cited
is "don't repeat yourself (DRY)". In the case of DB I/O, don't repeat error
handling and user messages in multiple source members. Encapsulate logic
like that in one place. Do the same for data validation, RI constraints,
locking policies, and business rules which are incidental to DB I/O.
I'm not suggesting that the examples cited in the redbook are how I would
do it. I just suggest that the general idea is architecturally sound. Use
the idea to reduce the overall amount of code to be maintained. If it
insulates programs from DB changes which occur over time, that's icing on
the cake.
midrange.com
