|
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] Joe, Could you refer to more info about the technique of encapsulate the database access in an object? or your class details? Thanks a lot. -----Original Message----- From: Joe Pluta [mailto:joepluta@PlutaBrothers.com] Sent: Thursday, October 04, 2001 10:21 AM To: java400-l@midrange.com Subject: RE: SQL update/insert for a string contain " ' " You're absolutely right, Dan. I assume that I will be writing for the AS/400. Any other assumption is a poor one for my clients. However, that's really not the issue here. The issue is a broader one: is SQL a valid approach when accessing AS/400 data from an OO language. The answer is a resounding NO! Since he's writing in Java, he could easily encapsulate the database access in an object. In fact, I'm giving a class on exactly that technique at COMMON. Then, if for some reason you need to access data on another database, you can attach a different data source and your application won't know you changed. Especially in an OO environment, it is never a valid argument to sacrifice performance for the sake of "possible futures". Since you can easily alter the behavior of any class, you should always write for performance, but encapsulate your code. If you think about it, SQL, with all its inefficiency, was simply a first attempt at encapsulating data access. With true OO languages, the requirement for this crude form of encapsulation has been removed, and so the argument of "maybe someday moving to a different platform" is removed. If you move to another platform, you'll have to rewrite your data access objects, but that should be a relatively trivial procedure. In fact, if you want to have one version of SQL and one version of native access, you have the best of both worlds. If your idea of delivering quality product is to sacrifice real performance for your user today for the sake of a possible easier conversion for yourself sometime in the future, then I submit that perhaps your definition of quality and mine are different. You want the soapbox back? <grin> Joe > -----Original Message----- > From: Eyers, Daniel > > > Not sure I agree with you here. Your assumption is that you will *always* > use the AS/400 for your hardware platform. *and* you assume that you will > *only* connect to AS/400s. If I wanted to migrate my applications off the > 400 onto some other package, I'd be hard pressed to convert the RPG and > COBOL to some other language. On the other hand, using the '400 as a > development platform (and using SQL) allows me to offer systems on other > platforms with little to no conversion. Finally, using RPG and COBOL > programs assumes that there is an adequate supply of COBOLers and > RPGers. I > don't know about you folks but I *certainly* don't believe that to be the > case. In fact, the AS/400 program at the local community college > is seeing > significant decline in enrollment... one of the hottest classes: > Oracle and > SQL. > > Having said that, I think each shop should consider carefully the decision > to use SQL or RPG and COBOL programs as their choice. Performance is a > crucial issue, however, I find I'm bound by bandwidth, not the response of > the 400. > > (getting off my soapbox) > > dan _______________________________________________ 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.
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.