|
> Does anyone have any references or sample > code which gives some guidance on structural > programming techniques for separating
display logic from business logic in RPG.
Firstly, I would try very hard to not think of 'structured programming techniques' as a mechanism for separating display and business logic. You can separate business logic from display logic whether you use structured, non-structured or OO. The decision to do so is an architectural decision, not an implementation decision.
By that, I mean to say that you can implement the idea of initialising a variable in several ways: MOVE, Z-ADD, INZ on D-specs, compile time table/array, etc. Any of these choices can be selected almost independent of the overall architectural design.
On the other hand, if the architecture requires that the variable initialisation data be provided by external means, you'd be able to choose between a data area, run time tab;e/array, file, user space, etc. Again, either of those implementation choices could be made without affecting the overall architecture.
This is a trivial example, but I hope it gets your mind running along the lines that the architecture stands mostly independent of the implementation. Yes, it's true that certain implementations are easier to do in order to fulfil an architectural requirement, but there is often (usually?) more than one possible implementation.
In the case of separating the UI from the business logic, you first need to consider the overall architecture. Can you use stored procedures? How about service programs? You may be able to use both mechanisms, or go down the web-services route. Any of these choices can be implemented using structured techniques, or not, as you choose.
Since very few of us have the luxury of architecting an entirely new application from scratch, it's likely that you're going to have to engineer this in such a way that you can call it from your existing application as well as the new UI. Service programs are an excellent way to get started in that direction in my opinion because you can wrapper service program procedures in a stored procedure and call it from Java or other ODBC application, which in turn can be subsumed into a web service fairly easily.
--buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
