RE: Porting Java applications from the 400 (was: SQL update/insert for a string contain " ' ")

I agree with your comments... Encapsulating the data calls is the best
approach.  However, using RPG and COBOL (in my mind) seems to blur the fine
line between the business logic layer and the database layer.  Where do you
do your validation?  Whose "really" in charge of choosing the records?  Or
do you completely stay away from SQL altogether, choosing instead to write a
new routine for every call?

I think that there is some room for RPG (but not COBOL *laugh*) to help with
the process; however, I'd rather have SQL that mostly works then have RPG
routines that *will not work* in any other environment.  Since the potential
of moving toanother platform is a very real one for me, I'm more apt to
adaprt an SQL-based solution.

dan


-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Thursday, October 04, 2001 11:17 AM
To: java400-l@midrange.com
Subject: RE: Porting Java applications from the 400 (was: SQL
update/insert for a string contain " ' ")


Buck, this is hardly ignorance.  It is instead one of the crucial points of
designing OO business applications.  The datasource concept I presented in
my previous post is the wahy to avoid that particular pitfall.  By dividing
your application into tiers - application, object and data - you effectively
separate your application from you database layout.

This technique is especially important in the case where the database is
fundamentally different.  This can even happen on a single platform, say,
during a merger.  By using a different data source for different objects,
you can actually treat them the same in your application.  Of course, you
will have to write different methods for the data sources, but you'll have
to do that at some point.  The best place to do it is in a single,
encapsulated location, rather than strung out all over your code.

Joe


> -----Original Message-----
> From: Buck Calabro
>
> Here's where my ignorance comes in.  There's some underlying logic that I
> haven't mapped out here; specifically calculating the detail subtotal (qty
> ordered * item amount) and adding the subtotal and the tax to
> come up with a
> total.  That seems straightforward enough unless the new system has a
> fundamentally different way of calculating the extension. The point being
> that the "calculate the total" logic is dependent upon the database design
> and will therefore(?) need to change to match the new SQL.  I'm ignorant
> because I don't know enough Java to say if the original coding would have
> built a separate class for each sub-function and then a larger class to
> assemble the total.
>
> Practically speaking, how likely is it that I can pick up my Java
> application, re-do the data access classes and be ready to go?

_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.