× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 10/2/07, albartell <albartell@xxxxxxxxx> wrote:

OK, let's look at this another way. Using "Classic I/O", you would have
to
find all the code that references the field anyway, so you aren't losing
anything there.

In the same breath we have to count the hours we saved NOT having to write
DB I/O code, and measure it against the time spent having to check all
references to a column that are "hard linked" in code.


Yes, but you only invest that time once, and with a little Code Generation
assistance this can be made largely trivial (hence the RPGBeans.com project
in the first place). Contrast that to making an application wide change,
which could be substantial, only to find out a week later the boss wants
another one so you do it all over again.

I'm not saying it's easy: as I've stated several times recently, it takes
lots of discipline. What I am saying is that I think it ultimately proves
worthwhile.

As for the rest of your post, you are trying to guard against projects where
you don't have time to plan for all current business logic and instead
default to putting a veneer over DB2 to protect your data. The more we
collaborate the more I think you want veneers not for DB I/O but instead
for
business logic changes. And if that is the case I think a better approach
would be to develop based on function vs. tables. For instance, instead
of
coding all of the DB I/O for the 5 files it takes to calculate a price you
could instead code two procedures named Price_getWholesale and
Price_getRetail.


In OOP, you could actually do both if the situation demands it. The layer
of business rules could rely on the DB layer to retrieve data, which may
actually use Stored Procedures to access the multiple files. This approach
would definitely allow you to distinguish between the Database Structure and
the Object Structure which do NOT have to be the same. Having the Service
Program mirror the Database layout is just typically the first step for
procedural programmers to apply and embrace Encapsulation. Once you realize
the two are not necessarily tied together the sky's the limit.

I agree that it is the data encapsulation/protection that intrigues me most,
not necessarily outsourcing the DB access. Proper layering will also allow
the same business rules to be applied across different UIs. A CGI program,
a DSPF, or even a WebService could all rely on the same code to protect the
integrity of the Database.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.