RE: RPG redbook

I concede that the solution solves the author's (IMO) contrived problem. Other than that one case, what would it solve?

-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Monday, October 24, 2016 1:42 PM
To: RPG programming on the IBM i (AS/400 and iSeries) <rpg400-l@xxxxxxxxxxxx>
Subject: Re: RPG redbook

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.